I edited a file manually in the system partition and my phone didn't boot and I didn't have a CWM backup.
By creating a new backup in CWM and mounting the SD card, I could open system.ext4.tar with "7-zip File Manager" and change back what I messed up and restore the system partition successfully!
----
What I discovered was that the MD5 mismatch would still appear even if I changed to the new MD5 string by using a MD5 generator.
This is a problem in CWM and appears in Abyss Kernel and Francos Kernel (The ones I tried and newest version as of this date), BUT luckily, SpeedMod kernel saved me!
By emptying the whole nandroid.md5 file, SpeedMod kernel's CWM did not check the MD5 sum and the system partition got restored with the corrected files and the phone booted successfully.
Hope this helps others as well and hit the Thanks button if it did, Thanks!
Could you not just boot into recovery, mount the system partition and then connect via an adb shell and/or use adb pull/push on the problem file?
Your method seems good though.
knightnz said:
Could you not just boot into recovery, mount the system partition and then connect via an adb shell and/or use adb pull/push on the problem file?
Your method seems good though.
Click to expand...
Click to collapse
That would work too of course!
Though many basic user are not familiar with adb or think it's complex.
If not, your method works as well.
Off Topic:
You should add "then" and "than" to your list. Also a common mistake.
So I was able to do a full adb backup when I was on 4.1.2 before I updated to 4.2.2.. I wanted to do another full adb backup again on 4.2.2 before putting a recovery or custom rom on my device so it would be easy to restore back to my completely stock experience (with root) if I choose. But for some reason after letting it run all the way through (I let it run overnight since it takes so long) the backup is nowhere to be found which leads me to believe it failed somewhere along the way, but no errors are reported. Has anybody had this issue or have any advice on what may be going on? I've tried doing:
Adb backup -all
Adb backup -all C:\Users\Wyth\Desktop
Adb backup -all G:\ (external HDD)
Adb backup -all G:\xtzbackup (in case adb backup had some sort of bug saving to the root of the drive)
If anybody has any help or alternative solutions to creating a full system backup I'd appreciate it! Thanks in advance!
If you are going to supply a path and file name, don't forget the -f switch
dph3055 said:
If you are going to supply a path and file name, don't forget the -f switch
Click to expand...
Click to collapse
Thanks, that was absolutely the issue. I guess I did that the first time around but forgot the second. I ended up making the backup and then unlocking the bootloader. Unfortunately I forgot that it would completely wipe the internal storage rather than just a factory reset, so I lost my titanium backups. Tried to do the adb restore, and every time after the first app it would just reboot the device. After trying it many times I ended up using the adb extractor tool to create a tar from the backup. Apparently however the backup was no good because when extracting the tar after getting to a certain part every time it came up with unexpected end of archive. But I at least got most of the titanium backup folder out. Tried copying that to internal storage and it was permission denied. Copied it to external sd, and then on the tablet transferred it to internal storage. Then every time I restored any of the data, when I rebooted the tablet it would go into bootloops. After many ftf flashes and time wasted copying things back and forth all over the place I finally am basically just resigning to starting over. Boot into CWM and made a backup, and find that it makes the clockwork mod backup folder in data/media rather than the proper place in data/media/0 or even data/media/legacy. The option to backup to external sdcard also doesn't work, as it refuses to mount sdcard or external-sdcard. Needless to say the last 24 hours or so has been massive headaches. Is there a newer version of CWM for the tablet than 6.0.3.2? It seems pretty buggy and hard to believe that it is what everyone has been using as the button combination to reboot to recovery doesn't even work.
Btw, I'm trying to do this on the stock sony 4.2.2 firmware for sgp312.
Using kernel and recovery from here:
http://forum.xda-developers.com/showthread.php?t=2433466
with ftf from here:
http://forum.xda-developers.com/showthread.php?t=2424550
So im trying to restore CM13 (Temasek's Rom) back onto my phone after flashing the official 6.0.1 india rom and finding it quite basic tbh. For some reason it keeps failing to restore the Data section and ive copied the output below:
==> extracting: //data/app/com.facebook.katana-3/oat/arm/ (mode 40771, directory)
I:Extracting gzipped tar
Ipening as a gzip...
==> extracting: //data/app/com.facebook.katana-3/oat/arm/base.odex (file size 214532528 bytes)
tar_extract_file(): failed to extract //data/app/com.facebook.katana-3/oat/arm/base.odex !!!
I:Unable to extract tar archive '/external_sd/TWRP/BACKUPS/95f4b792/2016-06-19--07-23-55_cm_kltedv-userdebug_6.0.1_MOB30D_ab649f68a6/data.ext4.win002'
Error during restore process.
I:Error extracting '/external_sd/TWRP/BACKUPS/95f4b792/2016-06-19--07-23-55_cm_kltedv-userdebug_6.0.1_MOB30D_ab649f68a6/data.ext4.win002' in thread ID 0
I:Error extracting split archive.
Error during restore process.
extractTarFork() process ended with ERROR: 255
How can i get around this file? I really need to get my Messages, Social Media data and as much of everything back from the backup.
Hi,
i know that TWRP does not backup /data/media but it also ignores certain directories in /data.
For example "/data/anr".
TWRP version is the latest one, twrp-3.2.3-0-i9300.img, 2018-07-30
I checked the backupfile for /data with 7zip and some directories are missing, which are under /data when looking with inside TWRPs FileManager.
Some of those missing directories were empty ... but for example anr directory contains some trace logs.
Anyone knows after which rule directories get ignored by TWRP? Bug? Feature? whatever?
Tried restoring a nandroid backup of the data partition with twrp.
also copied the /data/media partition back from an external copy.
when booting up the phone immediately reboots back into twrp with an error message:
Android Rescue Party...
The reported problem is:
'--reason=set_policy_failed_:/data/vendor'
the vendor partition seems to be intact and i do have a backup of it taken at the same time as the data backup, restoring it doesn't yield results..
i'm wondering if FBE is throwing it off, as the backup was taken when the phone was decrypted (within twrp) however the data on the partitions is referencing some sort of encryption key?
you may also exhibit the following error upon bootup of a restored nandroid backup.
immediately after booting, the phone reboots back into recovery.
viewing the log in twrp will show:
Android Rescue Party...
The reported problem is:
'--reason=set_policy_failed_:/data/bootchart'
1. the solution to this is editing fstab.under twrp or other recoverymount /vendor from the mount icon.in twrp: Advanced > File Manager > /vendor/etc/fstab.qcomselect edit file under userdata, find where it says fileencryption=icerename fileencryption to encryptable.Original
Code:
/dev/block/bootdevice/by-name/userdata /data ext4 noatime,nosuid,nodev,barrier=1,noauto_da_alloc,discard wait,check,fileencryption=ice,quota,reservedsize=512M
Modified
Code:
/dev/block/bootdevice/by-name/userdata /data ext4 noatime,nosuid,nodev,barrier=1,noauto_da_alloc,discard wait,check,encryptable=ice,quota,reservedsize=512M
save file.
2. next delete the following directories:
/data/unencrypted
/data/misc/vold/user_keys
3. Lastly delete any of the existing files from /data/system/ :
locksettings.db
Gatekeeper.password.key
gatekeeper.pattern.key
locksettings.db-shm
locksettings.db-wal
recoverablekeystore.db
password.key
pattern.key
4. Reboot and re-encrypt
At this point rebooting from recovery will result in a running and successfully recovery backup.
one thing to note is the data and data/media partitions are at this point unencrypted
TRYING TO REINCRYPT NOW WILL FAIL to reencrypt got to settings > security > re set your pin or password for the phone
(optional) then select encryption and there will be an orange button to encrypt device.
the encryption process will take quite a while as it will reencrypt your entire phone.
The above doesn't work as it's trying to accomplish FDE, and the fstab line for encryptable=ice, isn't compatible with this.
i could not find an fstab string to follow the same option but for FBE.
Thanks for sharing, nice guide to disable forced FBE encryption! I think this applies to Android 12+ in general, not just OnePlus devices.
I ended up with the same problem on my Mi 10 Ultra with MIUI 13 after a /data partition restore and it was a real pain to solve ("set_policy_failed:..." rescue party error for different directories). It's strange though why it fails to set the fscrypt policy for existing directories with no policy, correct permissions and SELinux context...
(Btw: whether a fscrypt policy is applied to a directory ("is this directory encrypted?") can be checked with fscryptpolicyget in terminal.)
Unfortunately, this didn't directly solve my TWRP backup restore problem and I still had to do a manual restore, but now I can at least disable FBE and it's always nice to have actual control over the device you paid money for (you should really have control by default, but oh well...)
(Some of) the troubleshooting I did:
Like I mentioned, I first thought the issue might be with the SE linux context, so I tried running restorecon, but this didn't help - I eventually found that in init.rc, restorecon is usually already automatically run during each boot for directories under /data/... so running it manually makes no difference.
To edit /vendor/etc/fstab.qcom (or /system) on my device, I had to first disable the shared blocks EXT4 optional feature. I followed this nice guide to unpack/repack super.img. But this is missing the step for disabling shared blocks: when I tried to mount any of the unpacked images (e.g. vendor.img) as R/W, it failed with the useless generic error:
wrong fs type, bad option, bad superblock on ...
Click to expand...
Click to collapse
Then dmesg gave me another clue, but at the same time was still cryptic and not immediately helpful:
EXT4-fs (loop*): couldn't mount RDWR because of unsupported optional features (4000)`.
Click to expand...
Click to collapse
So I guess 4000 is the code for shared blocks and you can disable these with e2fsck -E unshare_blocks <your .img file or loop device> (and probably need a filesystem check with e2fsck -yf <file>). Again very annoying that these numerical feature codes are not mentioned anywhere in the e2fsck manual pages for example.
Anyway, I was finally able to either:
1. mount vendor.img on my PC (mount -o loop vendor.img /mnt/vendor) and edit the /mnt/vendor/etc/fstab.qcom right there before repacking the .img and flashing the new edited super.img to my device
or
2. just repacking the vendor.img with shared blocks disabled and size increased (resize2fs vendor.img <new size>) and flashing the new super.img without other modifications - this way /vendor can also be mounted as r/w in Android and changes made later (mount -o remount,rw /vendor).
The worst part is that in the end, even with decryption disabled and the keys deleted, the device still wouldn't boot after a /data restore from TWRP (and after multiple days spent on debugging )... I still had to manually extract the TWRP backup and move directories/files individually - thankfully no issues with app/ or data/ - I think the problem was with some files in either system/ or misc/, but idk for sure. I just manually went through and kept only what seemed important (saved wifi APs, BT devices, SMSs etc, but not saved accounts). And after this it finally booted with all my apps and (most of) my settings!
(Btw2: a TWRP/nandroid backup is apparently just a bunch of separate tar.gz files, not a split archive, so you can just extract them with for file in ../data.f2fs.win*; do echo "extracting $file..."; busybox tar -xzf $file; done)