Hi everyone,
my N7 (unlocked, stock, latest OTA, maybe was rooted) is not booting past the Google logo. I can access bootloader and recovery and through custom recoveries adb shell sbin/dmesg. also in stock adb sideload works. but when it is stuck in google logo it is detected as nexus 7 but I can't access it through adb (no devices listed).
What I did already:
stock recovery: factory reset
cwm recovery: wipe dalvik cache, fix permissions
reflashed factory image JZO54K and JOP40D
formatted /system and reflashed
fastboot oem lock & fastboot oem unlock: after this it will show the boot animation for ~7s and reboot
also i waited 20mins after flashing factory images - enough so it at least can show the boot animation
this is what fastboot currently shows:
FASTBOOT MODE
product name - grouper
variant - grouper
hw version - ER3
bootloader version - 4.13
baseband version - n/a
serial number - 015d2109f31c0415
signing - not defined yet
LOCK STATE - UNLOCKED
here are two dmesgs: http://pastebin.com/T8pexUa3 and http://pastebin.com/y2sXSC5n
and here's the video of a startup after fastboot oem lock + unlock: http://www.youtube.com/watch?v=Sj3E3Emkz2U
and here's a log of one flash: http://pastebin.com/z5Bue4jL where everything seems perfectly fine
Some more symptoms: non of openrecovery-twrp-{2.3.3.0, 2.4.0.0, 2.4.1.0}-grouper.img are properly booting (only splash screen is displayed) and when I try to do some tasks like mount /system with cwm 6.0.1.0 or factory reset with twrp 2.2.1 (part of galaxy nexus 7 toolkit) the recovery will freeze so I have to reboot. also cwm gets awfully slow after some tasks.
I am out of my wits, can anyone help? If you give me instructions I can provide more dmesgs.
hi aha27,
Sorry about your problem. You are to be commended though, for the preparation and detail you provided in describing your situation - too bad most are not that thorough.
That video is an unusual bootloop. With "normal" bootloops the kernel stays up and the android layer cycles endlessly in it's startup checks - but your video looks much more like a kernel panic occurs, as the screen goes back to a bootloader display.
I looked briefly through one of your dmesg boot logs, and didn't spot anything unusual. The facts that:
(a) you can successfully re-flash stock roms, including file system re-creation
(b) you can run adb shell commands interactively
is evidence that the kernel has no difficulty booting and that perhaps the flash filesystems are all OK too.
What sticks out is your report that the recoveries also do not proceed completely to show their touchscreen interfaces.
Here is something to try
(1) perform soft-boots of the recovery with fastboot, for example:
fastboot boot openrecovery-twrp-2.3.3.0-grouper.img
As this requires no writing nor reading of the eMMC Flash memory, if it fails to setup the display correctly, perhaps you have a hardware problem that is unrelated to flash memory. (As you tried multiple recoveries, you may have already done this - it wasn't evident whether you flashed your different recoveries or soft-booted them)
Note also that you can run several adb sessions simultaneously, so in separate windows with the recovery running you can certainly be doing
C:\fubar> adb shell logcat > logcat_output.txt
and
C:\fubar> adb shell cat /proc/kmsg > kernel_log_output.txt
[ If you are using cygwin or linux you can spice this up a little, e.g.
$ adb shell logcat 2>&1 | tee logcat_output.txt
$ adb shell cat /proc/kmsg 2>&1 | tee kernel_log_output.txt
... as both of these block waiting for more output, in the latter case you get to see things happening in real time as well as capturing the output for later analysis ]
(2) see if anything is leftover in /proc/last_kmsg on the boot cycle immediately following the "bootloop". It might be possible to jump the device into fastboot mode by pressing Vol-Down the moment the Google logo first reappears. From there, soft-boot a recovery and capture the output of
adb shell cat /proc/last_kmsg
(3) Start your adb server on the PC and launch the "bootloop" and see if you can get a shell before the crash occurs. If you can get one before the crash occurs maybe you will be lucky enough to catch a problem via
adb shell cat /proc/kmsg
or
adb logcat -v threadtime
Note that if you have installed a fresh ROM, you can toggle ADB debugging on by mounting /data and
# mkdir /data/property
# chmod 700 /data/property
# echo -n 'mtp,adb' > /data/property/persist.sys.usb.config
# chmod 600 /data/property/persist.sys.usb.config
(4) I also noted your comment about "freezing if I mount /system". Note that when you flash the factory image, /data and /cache are handled differently than /system, even though all 3 are ext4 filesystems. For the first two, the process is "erase, mkfs, write", whereas for /system all you get is a "erase, write". So here is the deal - if a mke2fs filesystem is created, that means for /data and /cache that the bootloader is actually mounting those partitions (as ext4 filesystems) and restoring into them file by file. Otherwise, a "blob"-type write would just overwrite the newly created ext4 filesystem metadata.
/system is handled differently though - notice in the factory install logs there is no detail about filesystem creation for the /system partition? That's because Google is using a "sparse ext4 image" format for the system.img file, and it can actually write this to the /system partition as a binary blob.
So, on the chance that there is something wrong with the system partition, why don't you manually create the /system filesystem by hand to see if any errors occur? e.g.
mke2fs -T ext4 -m 0 /dev/block/mmcblk0p3
If this proceeds without error, try installing a dev ROM (not a factory ROM) and see if you can get further along.
The one thing which is fortunate about your situation is that you can return your device through flashing to complete factory stock, including locking the bootloader... if returning the device (via a warranty return/RMA) process is an option for you.
Whew that was a lot of typing. I think I am done for the day.
bftb0
bftb0 said:
That video is an unusual bootloop. With "normal" bootloops the kernel stays up and the android layer cycles endlessly in it's startup checks - but your video looks much more like a kernel panic occurs, as the screen goes back to a bootloader display.
Click to expand...
Click to collapse
This is the bootloop occurring once after doing fastboot oem lock / fastboot oem unlock - after the next reboot it stays at the Google logo without rebooting again.
(1) perform soft-boots of the recovery with fastboot, ... As this requires no writing nor reading of the eMMC Flash memory, if it fails to setup the display correctly, perhaps you have a hardware problem that is unrelated to flash memory. (As you tried multiple recoveries, you may have already done this - it wasn't evident whether you flashed your different recoveries or soft-booted them)
Click to expand...
Click to collapse
some were soft-boots some were with flashing of recovery, but CWM recovery hangs in either boot type after mount /sdcard or mount /user and mount /system.
I also tried some different versions of openrecovery-twrp-XXXX-grouper.img and none of it would start up.
Note also that you can run several adb sessions simultaneously, so in separate windows with the recovery running you can certainly be doing
C:\fubar> adb shell logcat > logcat_output.txt
and
C:\fubar> adb shell cat /proc/kmsg > kernel_log_output.txt
Click to expand...
Click to collapse
Ok, when I am in recovery I can mount /system and use /system/bin/logcat but there are only three lines with "scanline" something (do you need this?)
(2) see if anything is leftover in /proc/last_kmsg on the boot cycle immediately following the "bootloop". It might be possible to jump the device into fastboot mode by pressing Vol-Down the moment the Google logo first reappears. From there, soft-boot a recovery and capture the output of
adb shell cat /proc/last_kmsg
Click to expand...
Click to collapse
I couldn't go to fastboot when the Google logo appears but last_kmsg is this -> http://pastebin.com/VkmNdM5d
After oem lock / oem unlock and the reboot (like in the video) I managed to get into fastboot and recovery, here is the last_kmsg -> http://pastebin.com/wR1yptWr
(3) Start your adb server on the PC and launch the "bootloop" and see if you can get a shell before the crash occurs. If you can get one before the crash occurs maybe you will be lucky enough to catch a problem via
adb shell cat /proc/kmsg or adb logcat -v threadtime
Click to expand...
Click to collapse
nope. wasn't able to get a shell although I activated debugging with your procedure:
Note that if you have installed a fresh ROM, you can toggle ADB debugging on by mounting /data and
# mkdir /data/property
# chmod 700 /data/property
# echo -n 'mtp,adb' > /data/property/persist.sys.usb.config
# chmod 600 /data/property/persist.sys.usb.config
Click to expand...
Click to collapse
Still no adb while stuck at Google logo
/system is handled differently though - notice in the factory install logs there is no detail about filesystem creation for the /system partition? That's because Google is using a "sparse ext4 image" format for the system.img file, and it can actually write this to the /system partition as a binary blob.
So, on the chance that there is something wrong with the system partition, why don't you manually create the /system filesystem by hand to see if any errors occur? e.g.
mke2fs -T ext4 -m 0 /dev/block/mmcblk0p3
If this proceeds without error, try installing a dev ROM (not a factory ROM) and see if you can get further along.
Click to expand...
Click to collapse
wow - why would they do that? Anyway, I flashed recovery-clockwork-6.0.2.3-grouper.img and was able to format:
Code:
~ # mke2fs -T ext4 -m 0 /dev/block/mmcblk0p3
mke2fs -T ext4 -m 0 /dev/block/mmcblk0p3
mke2fs 1.41.11 (14-Mar-2010)
Filesystem label=
OS type: Linux
Block size=4096 (log=2)
Fragment size=4096 (log=2)
Stride=0 blocks, Stripe width=0 blocks
41664 inodes, 166400 blocks
0 blocks (0.00%) reserved for the super user
First data block=0
Maximum filesystem blocks=171966464
6 block groups
32768 blocks per group, 32768 fragments per group
6944 inodes per group
Superblock backups stored on blocks:
32768, 98304, 163840
Writing inode tables: done
Creating journal (4096 blocks): done
Writing superblocks and filesystem accounting information: done
This filesystem will be automatically checked every 39 mounts or
180 days, whichever comes first. Use tune2fs -c or -i to override.
and with adb sideload tried to install pa_grouper-3.00-09FEB2013-203806.zip. But it stopped at "Installing update..." (the cat /proc/kmsg is here: http://pastebin.com/rjd3b1iZ). I tried it again and again it stopped at Installing update, and here is the last_kmsg and the kmsg again: http://pastebin.com/gPBe7JFD and http://pastebin.com/uXHbX3we.
The one thing which is fortunate about your situation is that you can return your device through flashing to complete factory stock, including locking the bootloader... if returning the device (via a warranty return/RMA) process is an option for you.
Click to expand...
Click to collapse
Since everything failed I guess that's my only option, unless there is something in the logs ... maybe you could take another look?
Whew that was a lot of typing. I think I am done for the day.
Click to expand...
Click to collapse
And I am very thankful for your help!
aha,
I am travelling now, so there is a bunch of stuff I can't do easily right now... but I will have a look at the pastebins to see if anything jumps out at me.
Stay tuned.
aha27,
I looked at your pastebins. The only thing that seemed odd was the complaints about the cache partition (mmcblk0p4) in the kmsg logs. But it only appeared one time - hardly compelling.
The only other thing I could suggest is perhaps look in the recovery logs ( /cache/recovery/recovery.log or /tmp/recovery.log) for the recoveries that hang (but you can still communicate with). Maybe there are some crumbs in there that will put you on the correct trail.
FWIW, when I boot my N7 (JOP40D), it does take quite a bit of time for adb to come up - so if the initial OS boot was getting wedged before that happened maybe that explains why you are not seeing it even though you diddled with /data/property/persist....
I haven't looked into this, but is it possible to modify default.prop in the ramdisk so that the adb service gets started earlier? You would have to unpack & repack a boot image to do this. Actually, now that I think of it, you could just modify the "adbd" service definition in the /init.rc file in the ramdisk so that adb is not contingent on a getvar/setvar variable. Perhaps that would get adb running earlier in the OS boots that are hanging, and you might have a chance of observing more things.
I seem to be running out of ideas. With a lot more work, you could implement all sorts of unattended/blind captures though. For instance, a "one-shot" service definition can call a script that starts yet another script - but puts the 2nd one into the background. That way the oneshot service does not block init - and the second script can do strange things such as periodically record dmesg output or logcat output into files in /tmp and then copy them to the /sdcard once it is mounted. This would give you a way to observe stuff going on in the Android boot (after the fact) even if you can't gain realtime access via adb. But, this does require that you unpack, modify, and re-pack boot images.
Well, there's a few ideas. They seem to require progressively more work, though.
Good luck with your tab.
Thanks thanks thanks, but ...
Thank you very very much for the time you invested in my problem, :good:
but this:
bftb0 said:
aha27,
I haven't looked into this, but is it possible to modify default.prop in the ramdisk so that the adb service gets started earlier? You would have to unpack & repack a boot image to do this. Actually, now that I think of it, you could just modify the "adbd" service definition in the /init.rc file in the ramdisk so that adb is not contingent on a getvar/setvar variable. Perhaps that would get adb running earlier in the OS boots that are hanging, and you might have a chance of observing more things.
I seem to be running out of ideas. With a lot more work, you could implement all sorts of unattended/blind captures though. For instance, a "one-shot" service definition can call a script that starts yet another script - but puts the 2nd one into the background. That way the oneshot service does not block init - and the second script can do strange things such as periodically record dmesg output or logcat output into files in /tmp and then copy them to the /sdcard once it is mounted. This would give you a way to observe stuff going on in the Android boot (after the fact) even if you can't gain realtime access via adb. But, this does require that you unpack, modify, and re-pack boot images.
Click to expand...
Click to collapse
is too time consuming for me and as the tab is not too old, I will reflash it with stock, lock it and send it back. Initially I thought it could be solved, then I hoped that you could help me proving it is a hardware problem, so I'd have no problem getting it replaced, but let's see what Google tells me.
Good luck with your tab.
Click to expand...
Click to collapse
Thank you. Although it is off-topic: I talked to Google support (Germany) and they were absolutely not helpful. On the contrary, after I told them that I unlocked it to flash the previous image they told me, that as I have voided my waranty the could not guarantee that the tab will be replaced. And: they won't tell me (even after I asked twice), which options I'll have and what they will costcost, if it's a problem due to unlocking thus not covered by guarantee. That was no nice exceperience so far.
Well, if it turns out that Google/Asus refuses to do anything for you (seems hard to imagine, but I suppose all things are possible) and they return the tablet to you in the same condition, send me a PM or come back to this thread.
best
bftb0 said:
Well, if it turns out that Google/Asus refuses to do anything for you (seems hard to imagine, but I suppose all things are possible) and they return the tablet to you in the same condition, send me a PM or come back to this thread.
best
Click to expand...
Click to collapse
Hi I have almost the same problem, the thing is I'm using Mac and i don't have pc.
And my mac can't recognize my n7. I have installed TWRP v2.4.3.0
Please advice me.
Thank you
coszy said:
Hi I have almost the same problem, the thing is I'm using Mac and i don't have pc.
And my mac can't recognize my n7. I have installed TWRP v2.4.3.0
Please advice me.
Thank you
Click to expand...
Click to collapse
fastboot and adb work perfectly on the Mac.
http://developer.android.com/sdk/index.html
In fact, of the three platforms (Windows, Linux, Mac) setting up fastboot/adb on the Mac requires the least effort.
stuck on google logo after factory reset
My Nexus 7 locked up, got it to the recovery screen and did a factory reset. now I am stuck in a loop... it opens to the black screen with GOOGLE and stays there. I can get it to the bootloader screen but nothing more. Help please... I am NOT tech saavy!
mac20132 said:
My Nexus 7 locked up, got it to the recovery screen and did a factory reset. now I am stuck in a loop... it opens to the black screen with GOOGLE and stays there. I can get it to the bootloader screen but nothing more. Help please... I am NOT tech saavy!
Click to expand...
Click to collapse
I sent mine to Google and got a new one ...
Hi,
I need some help from experienced members.
I recently followed the guide carefully and updated my acer a500 to CM10.2
[ROM] [A500] Android 4.3 [CM10.2 Unofficial] Build 6
Everything went well as expected and even used the new ROM and the tablet for about 4 days without any issues. The device had turned off due to low battery and when i tried to turn back on, it is stuck in initial boot with the android robot picture stating booting primary kernel. It just stays here for ever.
I can access the recovery menu and have tried to reload the Rom and gapps files after doing a wipe; however have had the same result.
As i cannot boot, i am unable to connect and transfer any other rom files to it. What should i do? I need your help please.
Still looking for help
As mentioned previously i am unable to load to primary boot, as it just hangs at the android logo.
I am able to go into recovery menu, however when i goto install from internal storage it says "No Files Found".
I dont seem to be able to access the internal storage, please help.
srskiller said:
As mentioned previously i am unable to load to primary boot, as it just hangs at the android logo.
I am able to go into recovery menu, however when i goto install from internal storage it says "No Files Found".
I dont seem to be able to access the internal storage, please help.
Click to expand...
Click to collapse
Not sure if I have an answer for u but think I'd be trying wiping data and both caches. If that don't work then erase data/media.
If still no joy, then run babsector.rar file. Its an all in one tool that will reset partitions and flash the v8 bootloader and cwm. If it throws an error pls post the output.
You could also try the rom thread in case oyhers have reported similar issues
dibb
Solved
Managed to fix it.
Problem i was having was that i was not able to access the internal storage via recovery; as it kept saying no files found and that it could not even mount the drive.
I had to use a USB thumb drive, made it to boot as /sdcard and then copied my ROM file and gapps file on it. Then did a restart to recovery and installed the ROM and gapps files.
I was then able to boot normally and also had access to internal storage.
Hope this helps someone else.
Earlier: when i had it stopped at android logo; i also tried babsector and i also did the following:
Connect the tablet to the PC in RECOVERY. At this point, ADB should work. If not, check the drivers on the PC - I had to manually specify the Acer ADB Composite driver.
* Open a Command prompt window
* Start ADB shell by typing:
ADB SHELL
* Now execute the following:
mke2fs -j -b 4096 /dev/block/mmcblk0p8
tune2fs -O extents,uninit_bg,dir_index -C 1 /dev/block/mmcblk0p8
e2fsck -fy /dev/block/mmcblk0p8
I ask to help to unbrick the phone. Prehistory. After an unsuccessful firmware phone has a brick. The phone is not detected by the computer (Unknown device). Reinstalling the drivers does not help, closing testpoints does not solve the problem. The only option is to create a bootable flash drive and flash it from under it. To do this, you need a complete dump of the phone. This is the request. Please make a complete dump of the phone with the extension * .img. Script for adb I attach Adb shell su Adb shell dd if = / dev / block / mmcblk0 of = / sdcard / image.img I am hope for your help
Damagar84 said:
I ask to help to unbrick the phone. Prehistory. After an unsuccessful firmware phone has a brick. The phone is not detected by the computer (Unknown device). Reinstalling the drivers does not help, closing testpoints does not solve the problem. The only option is to create a bootable flash drive and flash it from under it. To do this, you need a complete dump of the phone. This is the request. Please make a complete dump of the phone with the extension * .img. Script for adb I attach Adb shell su Adb shell dd if = / dev / block / mmcblk0 of = / sdcard / image.img I am hope for your help
Click to expand...
Click to collapse
And how will you be able to "flash it under it"?
I wrote the same on the basis of a dump, create a bootable flash and from under it my own