• After 15+ years, we've made a big change: Android Forums is now Early Bird Club. Learn more here.

Looking for help fixing a bootloop without data loss.

sniperfox47

Newbie
Aug 14, 2012
40
4
contents:
1) background (skip if you don't care)
2) info on the problem
3) what I've tried
4) summary

1) I've been having this problem since I got my N7 but since it was only there I thought it might be device specific. Now since updating to 4.4 kit-kat on my nexus 4 it's having the same issue so I thought I'd ask for some help. I'd like to solve it without losing my data if at all possible (a factory reset fixes it but I'd like to avoid having to do that once a week >.>)

2) I have 2 devices a nexus 4 and nexus 7. Both are rooted but totally stock. At the moment both are on the 4.4 KRT factory images. If my nexus 4 or nexus 7's battery dies, and I allow it to go more than 45 to 60 minutes without finding a charger the device will go into a boot loop on the next boot. The devices start to the point where adb is available and when I used logcat it looks like the device continually changes the owner of each app, tries to delete the data folder for it (failing) and then fails to re-create the data folder. I have attached about 80000 lines of logcat code but most of it is just repeats of the same info transferring between different users.

3) I have tried several things to try to fix it, and all have either failed or resulted in total data loss. I'll list them below:

factory reset: lose all data

delete /data/: Same as factory reset (since it's the same thing as a factory reset but includes the sdcard directory :p)

delete /data/data: Lose all data since I just deleted it, but it still won't boot. It gives different errors though, instead getting to the point where android is booting and crashing the system main server. Looks like there are missing library dependencies too. I've also included a logcat file for this one.

delete /data/system (specifically /data/system/user): Boots normally, loses all data

delete /data/app: Boot loop still happens but only on native (system) apps since the others are gone.


4) If possible I'd like to find a way to fix this issue without losing all my app data. Unfortunately I'm at the end of my technical expertise and need some help. I can provide any other required device information upon request. I'll appreciate whatever help you can provide in solving this puzzle.

P.S. unfortunately I've had to zip the two logcats because of the forum's file restrictions. Main is the logcat prior to deleting anything and the other is if I delete the /data/data folder.
 

Attachments

  • logcat.zip
    446 KB · Views: 84
curious is the phone rooted?

Yes it is. Unlocked, with su and busybox installed, but otherwise stock.

I know it's not really a "fix," but you really should try to avoid draining your device's battery to that point - it can actually cause damage to the battery, and decrease its capacity for holding a charge.

That's a very valid point (although I thought modern batteries were designed to avoid dangerously low charges), except when the battery can only last an hour of heavy use and random apps/wakelocks running in the background can kill it before I even take it out of my pocket. I use my phone heavily when I use it but don't use it often. By the time I check on it, it's usually already shut itself down from low battery so this is a frequent issue.

I don't understand why android and the linux kernel it's running on (at least on these two devices) can't handle a safe shutdown at low power.
 
Upvote 0
How did you root both devices?

How was the N7 upgraded to Kitkat? Was it rooted before the update, or after?

What recovery and version are you running?

1) Both devices were rooted the standard way. By placing the supersu binary into the system 'rom' folder.

2) Both devices were updated to kit kat (as well as all other upgrades that have been done on them) by flashing the new factory image but omitting the userdata permission to avoid overwriting my user's data.

3) Both devices were unlocked immediately after receiving them. They were rooted prior to the upgrade but because of how I upgrade they had to be manually re-rooted after (I used adb from recovery to replace the binary).

4) Both Devices are on clockworkmod 6.0.4.3 recovery



I also assume you have a nandroid backup that you can restore as you have tested deleting all partitions/factory reset already.

I still don't understand what people mean by "nandroid" since it seems to mean very different things to different people... I don't have a raw nand dump for my device but I do have a clockworkmod backup. The backup is unfortunately from after the damage was done. I tried to obtain an ADB backup a few days ago (before the update) but adb update doesn't like me for some reason. It never seems to finish properly.

If you were asking about the backup as a possible solution, it's from after the damage so it's not. Making daily backups may wind up being a last ditch solution for me since it would save "most" of my data, but it takes up a ton of space on the phone and isn't very viable for me time wise.

Thank you all for all of the support you've given so far. I hope together we can find a solution.




[edit] This is probably a stupid question but I'll ask it anyways, factory resetting and then 'adb push'ing all of the /data/data/* folder's contents back into them isn't a viable option to fix this is it? I'd assume the permissions would get all messed up.
 
Upvote 0
1)
[edit] This is probably a stupid question but I'll ask it anyways, factory resetting and then 'adb push'ing all of the /data/data/* folder's contents back into them isn't a viable option to fix this is it? I'd assume the permissions would get all messed up.

I am beginning to wonder if the way you upgraded to kitkat with it's enhanced security is part of the issue of why the system is constantly trying to reclaim the data under its ownership.

What type of computer do you have available to you, Windows/Linux/Mac?
 
Upvote 0
texts and contacts aren't my big worry. Contacts don't even matter anyways since google now forces you to associate them with an account... *grrface*

bitterness aside, my main issues are my tabs and bookmarks on my browser, all of my settings and accounts for various apps, as you said game data for the few things I do play, and most importantly some of my apps for work that store their data in the app directory. Even the game data isn't all that important, I can just start over, but when I'm busy with work and umpteen bajillion other things I don't really have 3-4 hours to spend going through the settings for each of my apps and setting everything back up perfectly each time my device decides to shut itself down.

[edit]
I am beginning to wonder if the way you upgraded to kitkat with it's enhanced security is part of the issue of why the system is constantly trying to reclaim the data under its ownership.

The thing is Kit-kat works perfectly except when I let my battery die. And even if I factory reset (a.k.a erase userdata/flash the one partition I didn't flash) and then let the battery die it does the same thing. If I understand correctly, the userdata partition is left untouched when you update via the official zip as well.
 
Upvote 0
Well you certainly have an issue here, oddly enough having it happen on two different devices yet part of the same family dictates there is a common denominator to the issue.

It can be a common file used or common process employed, as the devices in theory have different images/kernels a common file being used can cause issues. Being certain the files were correct and MD5 verified for the devices in question only leaves the process as the lowest common denominator.

It could be a bad cable used for both devices.
It could be a corrupt/outdated/bugged ADB or OS install.
It could be the manner/commands in which files were applied to the devices.

Based on your observations there is something wrong with the system loading user data, as I stated earlier it seemingly is trying to claim ownership of the data and cannot for some reason.

I honestly believe at some point you will need to "lock n stock" the devices and start over to resolve the issues but you can certainly make sure your data has the best fighting chance to be restored.

I would accept the "lock n stock" option as vital to ensure that in the long term, as I build more data and customization's, that the tablet or phone is as bug and glitch free as possible. Dont ride a bandaid for a long time.

Start with a single device until you know for sure something works.

I intend on walking through a few options, starting at benign and ramping up to last resort, You can stop at any point that is acceptable to you.

For the purpose of simplifying the process, the CWM recovery backup of your device is the "nandroid". I would ensure you know the nandroid is valid and stored safely off the device. If you have restored the nandroid once already then you know it is valid, just keep it safe.

I would suggest using Wug's Nexus root toolkit (NRT)- Nexus Root Toolkit v1.7.9 | WugFresh

It simplifies the entire process, is a rather easy to use but an advanced tool to completely manage your Nexus devices. It automatically gathers all the files you need to flash any factory image for nexus devices or just parts and pieces of it.

Make sure you have the proper device and build set in NRT that you are working on, or desired biuld you want to advance to when flashing upgrades or desired full factory image.

Using recovery, try triggering the "reset permissions" option in CWM. Test for a bit.

Using NRT or ADB, try flashing just the stock kernel. (option is available under advanced settings in NRT). Test for a bit.

Using NRT, go into "Options". Under the Flash Stock tab enable "No wipe mode", read and accept the warning, and apply. Flash Stock/unroot and test. You can root again after using NRT if that works.
NOTE - If you change the device in Nexus Root Toolkit you will have to go back into options and ensure no wipe mode is still enabled if so desired. Never assume "no wipe" mode is still enabled.

Remember at any point you can restore your nandroid in CWM recovery.

If none of the above work then you need to backup your app data and trigger NRT's "stock n lock" option using the android 4.4 profile if you so desire.

You can backup your app data using three different options -

1. Helium - https://play.google.com/store/apps/details?id=com.koushikdutta.backup

2. TitaniumBackup - https://play.google.com/store/apps/details?id=com.keramidas.TitaniumBackup

3. Nandroid Manager (Use after a complete wipe to restore app data extracted from your nandroid) - https://play.google.com/store/apps/details?id=com.h3r3t1c.bkrestore


Helium - I have used this before and it is very reliable. You can run Helium right on a rooted device, or if unrooted you need to temporarily pair your device to a computer (Vista+,Linux, or Mac) so that Helium Desktop can enable apk backup on your device.

Alternatively you can run Helium webserver (wifi only) on your device, browse to the IP address and port displayed on your device screen with any browser, and trigger the backup and offload it right onto your computer.

Once run, find the Carbon folder on your device and copy it somewhere safe.

TitaniumBackup - I have TB pro on all of my rooted devices, hands down the most comprehensive app backup/restore and system management utility there is. Worth every dollar of its almost 7 dollar price tag. Not quite KitKat ready if you change to ART runtime.

Using TB you can backup apps and its data, pro features allow you to label apps and schedule automatic daily app data backups and have TB pro upload any changes to Dropbox, Box, or Drive cloud storage so your data is safe and restorable even if you totally lose your device.

Locate your TitaniumBackup folder (Normally named just that) and related settings folder (normally labeled DATA on your SD card), move them off your device and somewhere safe if you dont use a cloud service.

Nandroid Manager - I have not personally used yet but very highly rated, recognizes both TWRP and CWM nandroids. Should be able to extract your apps and data from your nandroid if everything goes well.

Consider this your security blanket last chance kinda thing if everything else fails, Use Helium or TB as well.

Once you are sure you have your relevant data backed up outside of your nandroid, I would suggest you stock n lock the device using NRT set to the profile you desire, Kitkat 4.4 for example.

Remember when working with a current system make sure the current device build is selected in NRT.

When you want to re-flash completely select the desired build you want to end up with in NRT.

Once you are stock, unrooted, and locked proceed to unlock and root the device again.

Make a nandroid of the fresh device, apply your backups, and set it back up like you want.

I know I may have been a bit windy but if you have any specific questions, need clarification on anything in this post, or simply have more questions just ask, I will be here.
 
  • Like
Reactions: Mikestony
Upvote 0
Well you certainly have an issue here, oddly enough having it happen on two different devices yet part of the same family dictates there is a common denominator to the issue.

It can be a common file used or common process employed, as the devices in theory have different images/kernels a common file being used can cause issues. Being certain the files were correct and MD5 verified for the devices in question only leaves the process as the lowest common denominator.

It could be a bad cable used for both devices.

When flashing I always use the factory provided USB cable. I do so specifically because I know some phones such as my old Galaxy nexus do not follow the standard properly and rely on certain things in their cable.

It could be a corrupt/outdated/bugged ADB or OS install.

A corrupt ADB install may be a possibility (although it would have to be the case on two different computers). As far as a corrupt OS install, I verify the files md5 and sha-1 to ensure data quality before flashing and only flash manually using the official tool (fastboot) to ensure that a third party tool isn't making an error.

It could be the manner/commands in which files were applied to the devices.

I can tell you the exact order of commands I use. They are as follows:
Code:
adb reboot-bootloader
fastboot flash bootloader bootloader.img
fastboot reboot-bootloader
fastboot flash radio radio.img
fastboot flash recovery recovery.img
fastboot flash boot boot.img
fastboot flash system system.img
fastboot reboot-bootloader
fastboot flash recovery clockworkmod.img
fastboot reboot
That was my entire update process. All of the images were the factory image (a.k.a. stock) ones other than clockworkmod.img which was my clockworkmod recovery. I took the liberty of simplifying the file names/paths to single words with extensions.

Based on your observations there is something wrong with the system loading user data, as I stated earlier it seemingly is trying to claim ownership of the data and cannot for some reason.

I agree with that statement, except for the system "claiming ownership". Rather it looks like the system is reassigning apps to new sandbox users, not taking control of them for itself. This is what I'm trying to find a fix for and what my question was all about.

I honestly believe at some point you will need to "lock n stock" the devices and start over to resolve the issues but you can certainly make sure your data has the best fighting chance to be restored.

I would accept the "lock n stock" option as vital to ensure that in the long term, as I build more data and customization's, that the tablet or phone is as bug and glitch free as possible. Dont ride a bandaid for a long time.

The device *is* completely stock. Whether it's locked or not should be irrelevant to any part of android besides the boot loader.

Start with a single device until you know for sure something works.

Easy enough. Since my Nexus 4 is required for work I need to get that one working asap

I intend on walking through a few options, starting at benign and ramping up to last resort, You can stop at any point that is acceptable to you.

For the purpose of simplifying the process, the CWM recovery backup of your device is the "nandroid". I would ensure you know the nandroid is valid and stored safely off the device. If you have restored the nandroid once already then you know it is valid, just keep it safe.
Already have it backed up to my computer. flashing userdata will delete the 'sdcard' since it's in the /data/media directory, so I had to back it up to my PC before that.

I would suggest using Wug's Nexus root toolkit (NRT)- Nexus Root Toolkit v1.7.9 | WugFresh

It simplifies the entire process, is a rather easy to use but an advanced tool to completely manage your Nexus devices. It automatically gathers all the files you need to flash any factory image for nexus devices or just parts and pieces of it.

Make sure you have the proper device and build set in NRT that you are working on, or desired biuld you want to advance to when flashing upgrades or desired full factory image.

Using recovery, try triggering the "reset permissions" option in CWM. Test for a bit.

reset permissions doesn't exist in CWM anymore since it hasn't actually done anything since... 4.0 I think? The developer removed it. [edit] correction 2.3 was when they added sdcard support for apps (API level 8) and when reset permissions became obsolete.

Using NRT or ADB, try flashing just the stock kernel. (option is available under advanced settings in NRT). Test for a bit.
Kernel already is stock. That's what's in boot.img among other things.

Using NRT, go into "Options". Under the Flash Stock tab enable "No wipe mode", read and accept the warning, and apply. Flash Stock/unroot and test. You can root again after using NRT if that works.
NOTE - If you change the device in Nexus Root Toolkit you will have to go back into options and ensure no wipe mode is still enabled if so desired. Never assume "no wipe" mode is still enabled.

I don't understand this one. If you flash a stock image it will already be unrooted since root lives in the /system/ path, which the system.img image overwrites. Can you please elaborate?

Remember at any point you can restore your nandroid in CWM recovery.

If none of the above work then you need to backup your app data and trigger NRT's "stock n lock" option using the android 4.4 profile if you so desire.

You can backup your app data using three different options -

1. Helium - https://play.google.com/store/apps/details?id=com.koushikdutta.backup

2. TitaniumBackup - https://play.google.com/store/apps/details?id=com.keramidas.TitaniumBackup

3. Nandroid Manager (Use after a complete wipe to restore app data extracted from your nandroid) - https://play.google.com/store/apps/details?id=com.h3r3t1c.bkrestore


Helium - I have used this before and it is very reliable. You can run Helium right on a rooted device, or if unrooted you need to temporarily pair your device to a computer (Vista+,Linux, or Mac) so that Helium Desktop can enable apk backup on your device.

Alternatively you can run Helium webserver (wifi only) on your device, browse to the IP address and port displayed on your device screen with any browser, and trigger the backup and offload it right onto your computer.

Once run, find the Carbon folder on your device and copy it somewhere safe.

TitaniumBackup - I have TB pro on all of my rooted devices, hands down the most comprehensive app backup/restore and system management utility there is. Worth every dollar of its almost 7 dollar price tag. Not quite KitKat ready if you change to ART runtime.

Using TB you can backup apps and its data, pro features allow you to label apps and schedule automatic daily app data backups and have TB pro upload any changes to Dropbox, Box, or Drive cloud storage so your data is safe and restorable even if you totally lose your device.

Locate your TitaniumBackup folder (Normally named just that) and related settings folder (normally labeled DATA on your SD card), move them off your device and somewhere safe if you dont use a cloud service.

Nandroid Manager - I have not personally used yet but very highly rated, recognizes both TWRP and CWM nandroids. Should be able to extract your apps and data from your nandroid if everything goes well.

Consider this your security blanket last chance kinda thing if everything else fails, Use Helium or TB as well.

Once you are sure you have your relevant data backed up outside of your nandroid, I would suggest you stock n lock the device using NRT set to the profile you desire, Kitkat 4.4 for example.

The problem with backing up my data using all of these apps is that they're android apps. I have titanium backup. I can't get to it because I'm stuck in the bootloop.
[EDIT] sorry, I misread there. If nandroid manager does what you implied it might be worth a try. The other two i'm not sure though.

Remember when working with a current system make sure the current device build is selected in NRT.

When you want to re-flash completely select the desired build you want to end up with in NRT.

Once you are stock, unrooted, and locked proceed to unlock and root the device again.

Make a nandroid of the fresh device, apply your backups, and set it back up like you want.

I know I may have been a bit windy but if you have any specific questions, need clarification on anything in this post, or simply have more questions just ask, I will be here.




Everything you posted in this topic was things that were the first things I checked into. I appreciate the help, and don't mean to sound ungrateful, but I'm looking for other alternatives here. The ideas you provided that I haven't already tried consisted of: A) Do a factory reset and B) lock your device and unlock it again (basically a factory reset), which is the thing I am trying to work around. I understand I can do a factory reset to fix the device but doing a factory reset every few days isn't very feasible.

I understand it's likely a library or permission error being caused somewhere by an incomplete shutdown and I want to figure out how to solve that so I don't continually loose my data in the future. Continual backups and biweekly factory resets are my -last- resort.

[edit] nandroid backup was a good suggestion. I'll look into it. I'd still rather find a way to fix this without needing a full data wipe, reinstalling all my apps, and then restoring all their data.
 
Upvote 0
Flash stock and unroot is an option in NRT, its the label on the option in the program. Yes its one in the same.

You have tried a factory image flash and extract your app data from the nandroid?

If you have titanium, why don't you just restore the backups you made with it starting over?

If you have these backups I have no idea why you are trying to solve a boot loop other than factory imaging the thing and picking your backup flavor.
 
Upvote 0
Flash stock and unroot is an option in NRT, its the label on the option in the program. Yes its one in the same.

Yeah. I realized that the second time reading through your post. I was reading through too fast and getting a little too defensive. forgot to mark that one with an edit when I went back to fix some stuff.

You have tried a factory image flash and extract your app data from the nandroid?

I'm trying that now. The reason I'm trying to find a way to just fix the data though is because like I said restoring backups is a long painful process and I don't particularly have the time to do it every two or three days. I'm trying your suggestion with nandroid manager to extract the data. but it's been roughly 20 minutes now and it's only done reading 84 of 322 apps. It hasn't even gotten to picking the apps for restore yet.

If you have titanium, why don't you just restore the backups you made with it starting over?

Like I said above. Restoring these backups takes a LOOOOOOOOONG time, and when I've got stuff I need to be doing I don't have hours here there and everywhere to spend making backups every night, transferring them to my computer (since USB-OTG doesn't work on my phone) and then restoring them all several times a week when it breaks.

If you have these backups I have non idea why you are trying to solve a boot loop other than factory imaging the thing and picking your backup flavor.
It's not the boot loop I care about. [edit] I do care about the boot loop too since I need to use a phone, but it's not my primary problem since it can be fixed in 2 seconds via a factory reset[/edit] It's protecting the app data so I don't have to do continual backups and restore them every two days.

To put it simply: The reason your solutions are not viable solutions to my problem is because my problem is finding a viable way not to use your solutions.
 
Upvote 0
If you know you have the data you need backed up already then you will be far better off starting over and nuke the device, restore a full factory image of your desired android flavor, restore only your app data using the time needed, then finally making a new nandroid image of your freshly setup device.

If you do that you will not need to restore it every few days or when it runs out of power unless there is something physically wrong with the device, in that case warranty/send it in for repair.
 
Upvote 0
If you know you have the data you need backed up already then you will be far better off starting over and nuke the device, restore a full factory image of your desired android flavor, restore only your app data using the time needed, then finally making a new nandroid image of your freshly setup device.

If you do that you will not need to restore it every few days or when it runs out of power unless there is something physically wrong with the device, in that case warranty/send it in for repair.

...How does making a new nandroid after factory resetting it help me? the data that I'm worried about is time sensitive. Even if I back it up every 24 hours it still may not be viable when I go to restore it.

As far as hardware concerns I doubt it's a hardware problem. The chances that two different devices with different hardware would both have the exact same hardware problem is infinitesimal.


getting back on topic

I tried to imply this in my original post but maybe I wasn't clear enough. I'm looking for some help with a low-level solution at the file-system/kernel level to get the data back up and working and correct the boot loop caused by the power outages.

Obviously the batteries aren't calibrating right for shutoff so I want to figure out what's breaking when they die, and how to fix it because that might give me some insight into how to fix the shut-down issue.

I do not want a solution that involves a factory reset and backups in any way shape or form since that's not even band-aiding the problem. It's like splinting a leg and then the splint breaks so you put another identical splint onto it.
 
Upvote 0
...How does making a new nandroid after factory resetting it help me? the data that I'm worried about is time sensitive. Even if I back it up every 24 hours it still may not be viable when I go to restore it.

As far as hardware concerns I doubt it's a hardware problem. The chances that two different devices with different hardware would both have the exact same hardware problem is infinitesimal.


getting back on topic

I tried to imply this in my original post but maybe I wasn't clear enough. I'm looking for some help with a low-level solution at the file-system/kernel level to get the data back up and working and correct the boot loop caused by the power outages.

Obviously the batteries aren't calibrating right for shutoff so I want to figure out what's breaking when they die, and how to fix it because that might give me some insight into how to fix the shut-down issue.

I do not want a solution that involves a factory reset and backups in any way shape or form since that's not even band-aiding the problem. It's like splinting a leg and then the splint breaks so you put another identical splint onto it.


Using your analogy, you are trying to heal a broken leg through prayer as you don't believe in splints and find a reason to break or refuse them.

Good luck with your issue.
 
Upvote 0
For a bootloop that starts at the splash screen, I would first try fastboot flashing the boot img. May not be a need to flash the entire package.

Was one of the first things I tried. The first time it happened on my Nexus 7 I was on a non-stock kernel so I did that to go back to stock. When it happened on my nexus just now (was on stock kernel already) I decided to try it anyways, and flashed the partitions one at a time, starting with boot, then bootloader and radio and ending with system.

Unfortunately it didn't seem to help.

Thanks for the ideas though.
 
Upvote 0
Was one of the first things I tried. The first time it happened on my Nexus 7 I was on a non-stock kernel so I did that to go back to stock. When it happened on my nexus just now (was on stock kernel already) I decided to try it anyways, and flashed the partitions one at a time, starting with boot, then bootloader and radio and ending with system.

Unfortunately it didn't seem to help.

Thanks for the ideas though.

That's a mind bender if there ever was one. If I read it right, you said a factory reset would fix the problem but reflashing stock does not? That's like a factory reset on steroids. Very perplexing.

Very much seems like a kernel level issue to me. Every sign points at that including the bootloop (again, if at or just after the splash screen repeatedly) which is why I suggested the boot.img only. That way there's no data loss.

Is your version of clockwork known to work with this device for other folks without issue? I can't really imagine it being a recovery issue but I guess you could try flashing a different version or a different recovery altogether if another exists for your device (TWRP?) And if you are theorizing it's a falsely reported battery level, you could try wiping batter stats from the advanced menu of clockwork I guess. Sorry if any of these ideas were mentione above or already stated as tried by yourself. I admittedly haven't read through the whole thread as I'm at work currently. Although I'd think reflashing the stock image in it's entirety would have served the same purpose and many others.
 
Upvote 0
Flashing stock -including the userdata partition- does fix it (but loosing all my userdata :p). If I omit the userdata partition it doesn't fix it. Like I said above though flashing that userdata partition is just a factory reset that also deletes the sdcard, no?

I've used several different versions of clockworkmod on both devices and at least on the N7 it happens regardless of the version. I can go digging around for an old version to test on my N4 if you think it would help.

I'm not sure what you mean by a kernel problem. From what the logcat report is saying I don't think it sounds like a linux initialization problem, rather a problem occurring in the initialization of android when it checks all the app data before booting. It looks like it's having permission problems with the /data/data directory (most likely with the library files since I believe those are done as softlinks) but I'm not sure what permissions are supposed to look like in there. I know each folder is supposed to be owned by a UID assigned to it's specific app but I don't know the details on that.
 
Upvote 0
Flashing stock -including the userdata partition- does fix it (but loosing all my userdata :p). If I omit the userdata partition it doesn't fix it. Like I said above though flashing that userdata partition is just a factory reset that also deletes the sdcard, no?

Ok, I see what you're saying now. And yeah, wiping userdata will delete the "sdcard" contents on your Nexus since those contents are actually stored on a partition rather than a traditional card.

I've used several different versions of clockworkmod on both devices and at least on the N7 it happens regardless of the version. I can go digging around for an old version to test on my N4 if you think it would help.
Not really, I was just making sure you were using a tried and true (and updated) version. I wasn't sure what was the gold standard for cwm on your device but it sounds like you're up to date.

I'm not sure what you mean by a kernel problem. From what the logcat report is saying I don't think it sounds like a linux initialization problem, rather a problem occurring in the initialization of android when it checks all the app data before booting. It looks like it's having permission problems with the /data/data directory (most likely with the library files since I believe those are done as softlinks) but I'm not sure what permissions are supposed to look like in there. I know each folder is supposed to be owned by a UID assigned to it's specific app but I don't know the details on that.

I thought kernel problem because bootloops (not to be confused with random reboots) that reoccur at that same point of the would be boot sequence could point to the boot.img. But it could also potentially point to system process misfiring at the time of boot too I suppose. :thinking:

Kinda hard to tell for sure, I was just going off my past experience where bootloops are usually resultant from a kernel problem or the lack of a data/dalvik wipe but that's more when flashing roms.

So I just read through your log. And honestly, I'm still not sure where the real problem lies in that area surrounding the boot failure. It almost seems to be indicating a missing system package/file. But how does that happen out of nowhere...i.e. after things have been running ok for awhile and all of a sudden this all resurfaces? The only idea I have left would be these:

1.) boot into recovery and wipe cache and dalvik cache. Then try rebooting to system if you haven't tried that already.
2.) remove all your user apps (play store apps) temporarily assuming you already have a backup of these apps via nandroid and/or Titanium that you could restore in the future. MAYBE, there's an app interfering with boot. The one thing I like about that theory is that it's happening on two separate Nexi. And it may be likely that you could have the same offending app installed on both devices since many of us tend to install the same stuff as we move along. Just a thought, especially since you're on 4.4 in both cases which would be more prone to app incompatibility issues.
3.) keep all apps but downgrade your OS and see if it still does it then.

Sorry, it's all I got. Still thinking on this one but this is a quandary to be sure.
 
Upvote 0
1.) boot into recovery and wipe cache and dalvik cache. Then try rebooting to system if you haven't tried that already.
2.) remove all your user apps (play store apps) temporarily assuming you already have a backup of these apps via nandroid and/or Titanium that you could restore in the future. MAYBE, there's an app interfering with boot. The one thing I like about that theory is that it's happening on two separate Nexi. And it may be likely that you could have the same offending app installed on both devices since many of us tend to install the same stuff as we move along. Just a thought, especially since you're on 4.4 in both cases which would be more prone to app incompatibility issues.
3.) keep all apps but downgrade your OS and see if it still does it then.

Sorry, it's all I got. Still thinking on this one but this is a quandary to be sure.

1) Yep, wiping dalvik cache and cache partition was already tried since it's one of the recommended ways to fix bootloops most places I looked. I also tried clearing them after each other thing I tried as well.

2) I already tried that. That's what I did when I deleted /data/app since all third-party apps reside here. I got the same logcat results except only on the native apps (apps in the /system directory)

3) Great Idea. Never even thought of that. I'll give it a shot.
 
Upvote 0

BEST TECH IN 2023

We've been tracking upcoming products and ranking the best tech since 2007. Thanks for trusting our opinion: we get rewarded through affiliate links that earn us a commission and we invite you to learn more about us.

Smartphones