Have been having all sorts of weird problems with Nandroid backup/restores. Essentially, here’s the symptoms of the problem – I’d get a nandroid and restore it successfully (Amon RA/CWM would report success) – however either will get stuck at boot or if it boots successfully, will have tons of FCs and/or data loss. In most cases, I would dread seeing the green Android on boot up asking me to log in to my google account 😦
Essentially, my nandroids were useless… to the extent that I had only one nandroid backup that was known to work – and I was keeping 4 backups of that lest I lose it somehow.
So today, thought I’d get deeper into it and see where the problem was
- It was unlikely that its a problem with CWM/AmonRA – I myself had an old working backup. Since my backups were created and restored successfully with MD5 verification, it seemed that there’s something wrong in the backup image itself.
- Still, that seemed inexplicable, since creating images just doesn’t seem that flaky. A couple of times after reboot, I had got a “UID has changed – it is recommended to wipe data” or something similar message – so I thought something was wrong with permissions after the restore. In any case, I tried the CWM menu item of fix permissions – but didnt get anywhere with that. At this point, I was desperate enought to get adb out !!
- Now in full blown investigation mode, I didnt care if I couldnt restore my data – just wanted to figure this thing out. So restored a “non working” backup and did a adb logcat while the phone booted… turns out that I was seeing tons of messages like so:
I/PackageManager( 205): /system/app/ContactsProvider.apk changed; collecting certs I/PackageManager( 205): New shared user android.uid.shared: id=10006 W/PackageManager( 205): System package com.android.providers.contacts has changed from uid: 10003 to 10006; old data erased
- So that explained what was going wrong… thought it would be an easy fix to do the ‘fix permissions’ thing in CWM advanced menu. Restored again and went over to the advanced menu, did fix permissions and rebooted. What I got was a big naught for all my work – same problems and no resolutions. At this point I was stumped enough – but sheer bull headedness forced me to look at the log again… and lo it says ‘data erased’. So that explains why fix permissions after boot wont work since the data is erased during boot itself!
At this point, the key to the problem was really understanding how and where android’s UIDs are generated, stored and regenerated. Headed over to Cyanogen wiki and read up the details on fix permissions which explained the packages.xml file. Somehow the packages.xml was borked in the nandroid (every time) and that was causing it to be regenerated.
Armed with that, got a germ of a solution in place, which is roughly
- Restore nandroid with borked packages.xml
- Let the system boot. Will lose data but a new packages.xml will be regenerated
- Reboot into recovery and adb pull /data/system/packages.xml out.
- Do an advanced restore and again restore the data only.
- mount /data and adb pull /data/system/packages.xml to compare differences. Found that packages.xml was indeed corrupt.
- adb push packages.xml (this is the generated one pulled in step 3) to /data/system. Now you have all the old data but the packages.xml is newly generated one and known to be valid. Obviously UIDs will mismatch – but fix permissions has a valid file to work on.
- Still in recovery, run fix permissions. It should fix permissions properly.