OK, so here's the problem:
Twice now in short succession my Nexus 4 has frozen when exiting a particular game ("The Room" by Fireproof, as it happens) and, upon performing a reset the device has come back up in a bootloop - stuck on the animated "X" icon. To cut to the short of it, in both cases I ended up having to go into recovery and perform a data wipe to get the device operating again. The device is more or less stock, rooted with Franco's kernel (which I've never had /any/ problems like this with before!).
I'm not precious about my device, so this is little more than an inconvenience, but happening twice in a week means that that the engineer in me wants to understand /why/ it happened.
So, what advice do people have for diagnosing a failed boot? Let me get this clear, I'm not wanting help to get the device working again (I can do that myself) but more a discussion regarding how to find the underlying cause of this issue.
So, there's the dilemma. Anyone got any thoughts?
(ps. I don't want to put people off The Room. The game itself is absolutely marvelous and for the moment, I've switched to playing it on the N7 instead )
OK, so have a Nandroid of the failing image. Logcat is in memory, so is there anything to be learnt from the contents of this backup?
daern said:
OK, so have a Nandroid of the failing image. Logcat is in memory, so is there anything to be learnt from the contents of this backup?
Click to expand...
Click to collapse
OK, so it seems that there is likely no persistent logs, so I've restored the image back and then booted while capturing logcat. It isn't actually bootlooping, but rather it's just failing to boot. Logcat output attached. I've also attached a "good" logcat from a more or less clean image.
Looking at the logs, the last thing of consequence in the bad log is:
I/SystemServer( 498): Account Manager
...where as the good log continues:
I/SystemServer( 498): Account Manager
I/SystemServer( 498): Content Manager
I/SystemServer( 498): System Content Providers
So, any magic thoughts?
Anyone got any insight?
Noone?
Related
I tried to png-optimize the froyo 2.2 rom i've been developing and got a bootloop issue.
adb logcat of boot > http://pastebin.com/MNBbUxPS
developers can you please take a look at this and tell me if you see whats wrong?
Thanks in advance
Nothing in that log jumps out at me, but I'm not an expert either.
I would think that if it was looping, you would see:
- more than 180 lines in the logcat
- giant blocks of logcat messages that repeat (if the fault occurs "late" in the boot process)
I suppose all sorts of things could go wrong, but generally an Android "boot" loop does not affect the kernel, just the entire Android Application sub-system (the Linux "kernel" is fine - it is the Android layer which is looping.)
If that is the case, an "adb shell" will not terminate during the looping behavior - and a logcat should continue to spew logging messages.
If you collect a lot of logcat data, finding the end of the repeating pattern of log messages might provide you with some insight as to where the nexus of the problem is.
If that doesn't work - divide and conquer using binary division (perform png-optimization on only "half" the ROM, and recurse that halving until you isolate the trouble).
bftb0
When I've had these kind of boot loops, there's usually been a Java exception of some sort that repeats (hence the loop). You can use ddms and get the warnings and errors only. It makes it easier to find the actual error that is triggered when the problem occurs.
Nothing in that log jumps out at me, but I'm not an expert either.
I would think that if it was looping, you would see:
- more than 180 lines in the logcat
- giant blocks of logcat messages that repeat (if the fault occurs "late" in the boot process)
I suppose all sorts of things could go wrong, but generally an Android "boot" loop does not affect the kernel, just the entire Android Application sub-system (the Linux "kernel" is fine - it is the Android layer which is looping.)
If that is the case, an "adb shell" will not terminate during the looping behavior - and a logcat should continue to spew logging messages.
If you collect a lot of logcat data, finding the end of the repeating pattern of log messages might provide you with some insight as to where the nexus of the problem is.
If that doesn't work - divide and conquer using binary division (perform png-optimization on only "half" the ROM, and recurse that halving until you isolate the trouble).
bftb0
Click to expand...
Click to collapse
Thanks to both of you for your help
btfb0, the device boots to the white 3 android's on skateboards screen and a few seconds later it shows up in adb devices, but when the loop occurs adb shell is terminated, and any logcat's running also terminate. The last line always is "I/SurfaceFlinger( 96): SurfaceFlinger's main thread ready to run. Initializing graphics H/W..." SurfaceFlinger is android's window manager, so the problem is definitely the png-optimize, and binary division sounds like a great idea, I didn't even think of that, thanks.
Well its working now, thanks for your help!
homewmt said:
Well its working now, thanks for your help!
Click to expand...
Click to collapse
Good!
Just curious, what caused the trouble? Did you isolate it to something, or did it just start working after one of your ROM flashes?
bftb0
Un-Bricking by Unlocking & Flashing CWM+CM7 (was: Accidentally deleted MediaProvider)
Hi!
When removing Bloatware with Titanium Backup a while ago, I accidentally missed a click (never used a touch screen...) and uninstalled MediaProvider, which I have not been able to recover since.
I tried putting the files back from a friend's HTC, which didn't work; after that I was told even the packages differ between manufacturers, so I tried getting them from a stock Bell Atrix .zip posted on these very forums, which didn't help either. Neither #android-root nor AndroidForums were able to help, thus I ask here: Can anyone tell me how to either make my system accept Bell's files, or where I can find a "vanilla" Motorola build?
(Problem is, the phone didn't come from a phone company, a friend of mine got it pre-release from his uncle who is with Motorola, so it may even be different from what hit the market later on...)
I guess the following information will help, it's a Titanium Backup info file for another componend I backupped shortly after:
#Titanium Backup
#Sat Feb 25 03:28:43 MEZ 2012
app_gui_icon=[...]
sys_ro.build.date.utc=1302536066
app_version_code=8
sys_ro.product.model=MB860
has_prefsdata_jpu=0
sys_ro.serialno=<xxx>
sys_ro.build.description=olympus-user 2.2.2 OLYEM_U4_0.44.0 578673 ota-rel-keys,release-keys
has_prefsdata=0
app_gui_label=com.android.providers.applications 2.2.2
sys_ro.build.version.release=2.2.2
app_apk_md5=1989ff2476ee73ad445760b9bef5f44e
has_dbdata=0
app_apk_codec=GZIP
app_is_forward_locked=0
app_is_system=1
app_label=com.android.providers.applications
app_version_name=2.2.2
generation=1
app_apk_location=internal
(Most of this is unnecessary, I guess, but I can't really be sure what you might need to judge what I would have to to...)
I would be very grateful for any help, it is extremely limiting not to be able to use any media capabilities.
So, thanks in advance,
David
maybe flash a new rom if your contacts are all backed up?
Hm, well, that would really be the last resort :\ In addition to losing all my data, I fear the risk of bricking it completely. Can't really be that I'd have to flash it just because two files are missing...?
Edit: I neglected to say that the files in question are MediaProvider.apk and MediaProvider.odex. I do only need to copy these to /system/app, right?
Intelensprotient said:
Hm, well, that would really be the last resort :\ In addition to losing all my data, I fear the risk of bricking it completely. Can't really be that I'd have to flash it just because two files are missing...?
Edit: I neglected to say that the files in question are MediaProvider.apk and MediaProvider.odex. I do only need to copy these to /system/app, right?
Click to expand...
Click to collapse
Yes, but you have to set the permissions same the other files in .system/app folder.
I have attached the missing files to this post. My gingerbread version is 2.3.4.
Good Luck!
Huh. Setting right permissions for the files from Bell had no effect; installing yours soft bricks it in an interesting way: Even with Early USB Enumeration, all I see is
# adb devices
List of devices attached
???????????? no permissions
Even with root. The LED flashes red, and after a minute it reboots. I had expected things not to work out, resulting in the deletion of your files, but that I screwed up _that_ bad after it didn't even seem to notice the right (?) files when they were there is kinda surprising.
The standard workarounds (adb kill/start server, MODE=0666 to udev or being root) change nothing about this. Time for hard reset?
Intelensprotient said:
Huh. Setting right permissions for the files from Bell had no effect; installing yours soft bricks it in an interesting way: Even with Early USB Enumeration, all I see is
# adb devices
List of devices attached
???????????? no permissions
Even with root. The LED flashes red, and after a minute it reboots. I had expected things not to work out, resulting in the deletion of your files, but that I screwed up _that_ bad after it didn't even seem to notice the right (?) files when they were there is kinda surprising.
The standard workarounds (adb kill/start server, MODE=0666 to udev or being root) change nothing about this. Time for hard reset?
Click to expand...
Click to collapse
I would hard reset too at this stage. I'm sorry it didn't work out.
Now, that's interesting. Factory reset didn't change anything.
Sorry for reply to self, but I was less than clear, so - help?
My next step would be to try to unlock the bootloader, then flash CWM and see if anything can be fixed that way; then, I would try flashing CM7 (or, more specifically, the Neutrino GT ROM) by CWM; then, I would try flashing it without. Is that a safe progression of attempts? Or have I possibly broken anything that would hard-brick it by any of these methods? And can you recommend any finer increments what I could do before / between / after those mentioned? I still have the option to apply an update in Recovery - is it possible, for instance, to put a .zip onto my SD that has 0 Byte MediaProvider files in it?
(I have thought about installing Neutrino for a while, and this seems to be a good time to flash it, as my data is cleared now anyways. To my understanding, this should not be any more dangerous than just re-flashing the Froyo that was there before, right?)
As an additional fact, ADB now doesn't detect any devices any more, even with Early USB. This could be because USB Debug is not a factory standard setting, though, as I reset it to factory defaults.
Also, the startup Moto screen behaves differently: It doesn't go to the point where the logo disappears in a flash, the background light switches off before that. As far as I can tell, the display still shows the animation, though, but it is not lit. Furthermore, the reboot seems to happen immediately after the animation has ended, and not 1-2 minutes later, like it was before the reset.
I would be grateful if anyone could explain what happened. To my understanding, a factory reset should clear /system, and the error started when I put some non-compatible .apks there, so I thought this would fix things. Is it possible something broke on the hardware side, when (for instance) 2.2.2 called a function that has had its parameters changes in 2.3.4?
[If a moderator reads this - does this qualify as a general Android question? I have no experience with different devices, so I'd be glad if you could decide if this thread has to stay here or if it can go to a sub-forum with a wider audience - General Android Q&A, for instance.]
Bump...
Success Neutrino up and running!
Hi. So, I've been doing a lot of troubleshooting on my N10. I started out not even knowing that Jellybean would prevent propper logcatting w/out root, but I've advanced to the point where:
1) I have CatLog writing logcat, every 1 line, to my SD card
2) I have Bootlog Uptime writing log files after a crash
3) I've even looked into trace.txt and the likes, after I found this post:
http://android.stackexchange.com/questions/14430/how-can-i-view-and-examine-the-android-log
But I'll be damned if I ever even see the word "fatal" in any of these logs. And I always see this:
No errors detected
Last reset was software reset (RST_STAT=0x20000000)
So what am I doing wrong? My N10, when on purely stock, seems to have SoD. Im on KTmanta now, and knock-on-wood-dont-see-SoD, but I do still get some reboots.
How does Bootlog Uptime know these are crashes?
Thanks XDA
Hi all,
Has anyone else experienced data corruption on the /system partition? I'll probably have to return my tablet for replacement, but am wondering if it's happened to anyone else, or if it's just me.
Background:
A few weeks ago my Nexus 7 rebooted itself and became stuck at the 'X' logo - recovered by doing a full system re-image. It then worked for a week or so, then suddenly everything started force-closing, and after reboot I was back at the 'X' logo hang. This time fortunately I had debugging enabled and was able to dig a little further - turned out that several files in /system/framework differed from the ones in the original system image, even though they'd only just been reflashed - restoring those files from the image was sufficient to repair the system.
Just tonight it started happening again, and yet again one of the /system/framework files had changed. Comparing against the originals, it looks like a small number of bit errors, rather than any deliberate attack. In this case, framework.odex had a little over 1000 bytes with 1- or 2-bit errors, mostly (~80%) changes from 0 to 1. At this stage, I'm presuming that some kind of hardware corruption is going on here (considering it's normally a read-only partition).
Regards,
Nathan
I have experienced significant filesystem (ext4) corruption in /system (cross-linked block allocations), but I haven't observe "bit rot" in individual files afaik. I suppose bit-rot in filesystem metadata could produce the symptoms I observed, so I can't rule it out.
I thought I had a working hypothesis about why it was happening, and attributed it to something I was doing in TWRP, but I haven't run that hypothesis down yet. I am using lightly-rooted stock, so when this happened to me, I had only done a few things in /system such as the SuperSU kit and adding in the AOSP stock browser.
Anyhow - for the moment - the bit rot you describe does sound like media read errors & probably different than what I experienced. In either case, I certainly sympathize - it doesn't exactly instill a sense of confidence.
I thought that eMMC flash was supposed to be a lot more robust than MTD flash - things like automatic block remapping & wear leveling inside the controller allowing ext3/4 to be safe to use without causing premature failure... and even more so (you would think) with filesystems which are mostly used with read-only mounts.
Anyhow - because it keeps happening to you - you might want to revert to pure stock & relock your bootloader if your tablet is still under warranty. The next time it happens, set up an RMA, factory reset (using the stock recovery...) and send it in. (Even though it is a legitimate warranty defect situation, you can't really describe your diligence in tracking the problem down.)
good luck
After working without a glitch for four years, my Nexus 7 (grouper) got stuck in a bootloop after I started it today. Thinking that something is probably wrong with cashe or dalvik cache I've cleared them. Now the bootloop is gone, but the device gets stuck on "Starting apps" after it finishes "optimizing" (filling in the dalvik cache). I would like to see what's going on but I have a problem doing that.
The problem is that I can't get the logcat to do the job. I've tried two "solutions" that seemed obvious, but (for some reason), none of them works.
First "solution": make a simple script and put it in /system/etc/init.d/:
#!/system/bin/sh
logcat > /sdcard/log.txt (set to 755)
I get the file, but even if I leave "Starting apps" to run for some time, when I turn off the tablet and look at the file it only has 65 lines and it still didn't finish initializing the hardware part. No information about started apps or anything. I can retrieve dmesg log from recovery but nothing interesting there as well.
Second "solution": I've tried to make it work trough init.rc, by following this https://stackoverflow.com/questions/17406209/enabling-logcat-in-init-rc (switched /cache/ to /sdcard/). But this also produces no results. Txt file is not generated at all
I don't know what I'm doing wrong.
I don't want to do a factory reset unless absolutely necessary (bunch of games with save files and other apps as well).
I can't do logcat trough adb since device is "unauthorized".
Any help is appreciated.
Thx in advance!
P.S. Using OmniROM (4.4.4)
Boot into TWRP and see if you can create or edit a text file. Reboot back into TWRP again and see if the change you made is still there. If it isn't, your flash memory has gone bad and you are in read only mode. This cant be fixed without a new motherboard. Hopefully this is not your issue.
Sent from my LGLS992 using Tapatalk
Sorry for the late reply, I was on vacation and I left the tablet at home.
The script I've mentioned was inserted trough TWRP so I think this confirms that you can write.
Also there is a log file created, as I've mentioned, it's just super short (I guess if it's in read-only mode there would be no output).