Related
In the process of trying to move apps to the SD card, I've mucked something up.
I did:
cp -rp /data/data /system/sd/data
Then, just for safekeeping, I moved the /data/data directory to /data/data.test just in case.
I then did a symlink as follows:
ln -s /system/sd/data /data/data
Upon reboot, I get the flashing android screen. I do not have a nandroid backup (yeah, I know....I really should do that one of these days), but I think all my data should still be there. I just need to remove the symlink and move /data/data.test back to /data/data and all should be well.
How can I do this? Wish there was a sticky thread on how to recover from stuff like this. Digging through all these threads is time consuming and difficult.
well.. from y own experiencie while the phone is stuck on the android flashing screen i am able o access it from my pc using adb so try that
adb shell rm -rf /data/data
than rename data.test to data
adb shell mv /data/data.test /data/data
should work
Ah...didn't realize I could connect via adb at that stage....guess I should have tried it.
That did indeed work. Thanks!
How to root Nook HD+ (and Nook HD too, I guess).
(Thanks for some useful ideas to sparkym3: http://forum.xda-developers.com/member.php?u=4411543 )
(tested only on 2.0.0 version (as comes out of the box), also works on 2.0.2
Get one of the attached files: root_win.zip if you are on windows, or root_unix.tgz if you are on Linux or Mac.
unpack the file to some dir and run "makeroot" on Windows or "sh makeroot.sh" on Mac/Linux
After a couple of reboots you should be able to do
adb shell and issue a "su" command in the shell and get the root prompt (#).
Thanks to someone0 for his prior investigations here.
Known bugs:
Superuser.apk does not really install because package manager could not be contacted.
Oh, and I think you'll find this interesting too:
Hai.
Kind of a two-fer, eh?
I noticed that people see their Nook HDs restoring to factory settings after 8 unsuccessful reboots next time you boot after rooting, so possibly there's some extra check somewhere.
Very sneaky on the B&N side, I'd say.
Hm, the 8 failed boot = wipe and restore has been true since the NC, and is valuable because it helps keep the device from getting bricked, also triggerable if the registration token doesn't match BN's reg token. I learned this early on by restoring a backup made before I'd erased and deregistered. I forget where the token lives, in /data/ somewhere.
I'll take a look at this on 2.0.2 this weekend - mine updated before I got ADB working so it restores to 2.0.2 now...
OK, so this approach does work with the 2.0.2 OS, and restarting the device does put it into a boot cycle. Very nasty.
Before I rebooted, I removed the post_boot_hook file and also got rid of the symlink; I'd say BN is doing some kind of inventory of what's in system and driving a reflash based on that.
My guess is it's not a very careful inventory, but it'll certainly be amenable to study now that we can get, at least temporarily, root.
Hm. Interesting -- my ability to mkdir /data/su is now gone after the restore. I wasn't able to do it the first time I tried, either - I suspect that there's something keeping some level of eye on that.
Oh, very uncool - in addition to resetting the system, they wipe personal data in the process. Losing the apps doesn't surprise me much. Losing the books I'd sideloaded surprises me.
roustabout said:
Hm, the 8 failed boot = wipe and restore has been true since the NC, and is valuable because it helps keep the device from getting bricked, also triggerable if the registration token doesn't match BN's reg token. I learned this early on by restoring a backup made before I'd erased and deregistered. I forget where the token lives, in /data/ somewhere.
I'll take a look at this on 2.0.2 this weekend - mine updated before I got ADB working so it restores to 2.0.2 now...
OK, so this approach does work with the 2.0.2 OS, and restarting the device does put it into a boot cycle. Very nasty.
Before I rebooted, I removed the post_boot_hook file and also got rid of the symlink; I'd say BN is doing some kind of inventory of what's in system and driving a reflash based on that.
My guess is it's not a very careful inventory, but it'll certainly be amenable to study now that we can get, at least temporarily, root.
Hm. Interesting -- my ability to mkdir /data/su is now gone after the restore. I wasn't able to do it the first time I tried, either - I suspect that there's something keeping some level of eye on that.
Oh, very uncool - in addition to resetting the system, they wipe personal data in the process. Losing the apps doesn't surprise me much. Losing the books I'd sideloaded surprises me.
Click to expand...
Click to collapse
Do the new HD & HD+ still allow you boot from the external sd card ?
roustabout said:
Hm, the 8 failed boot = wipe and restore has been true since the NC, and is valuable because it helps keep the device from getting bricked, also triggerable if the registration token doesn't match BN's reg token. I learned this early on by restoring a backup made before I'd erased and deregistered. I forget where the token lives, in /data/ somewhere.
I'll take a look at this on 2.0.2 this weekend - mine updated before I got ADB working so it restores to 2.0.2 now...
OK, so this approach does work with the 2.0.2 OS, and restarting the device does put it into a boot cycle. Very nasty.
Before I rebooted, I removed the post_boot_hook file and also got rid of the symlink; I'd say BN is doing some kind of inventory of what's in system and driving a reflash based on that.
My guess is it's not a very careful inventory, but it'll certainly be amenable to study now that we can get, at least temporarily, root.
Hm. Interesting -- my ability to mkdir /data/su is now gone after the restore. I wasn't able to do it the first time I tried, either - I suspect that there's something keeping some level of eye on that.
Oh, very uncool - in addition to resetting the system, they wipe personal data in the process. Losing the apps doesn't surprise me much. Losing the books I'd sideloaded surprises me.
Click to expand...
Click to collapse
if you put your books into /system/media, it will back them up to the cloud
Is it possible to push a new recovery with adb after rooting? The 8 failed boot repair is only possible with the stock recovery. But then again you may end up in an endless bootloop without it there to finish it's task. But maybe you can find and delete the trigger flag that starts the process.
leapinlar said:
Is it possible to push a new recovery with adb after rooting? The 8 failed boot repair is only possible with the stock recovery. But then again you may end up in an endless bootloop without it there to finish it's task. But maybe you can find and delete the trigger flag that starts the process.
Click to expand...
Click to collapse
stuff is best to be not mentioned. /sarcasm.....
recovery is signed, so it's not super easy to replace it with anything that would run.
The unsigned bootloader trick at the moment requires a boot from sdcard.
shouldn't step 8 & 9 be outside the code block?
verygreen:
I just want to thank you for your all your work on the Nook series. I've been using your "size-agnostic method ..." tools and process to run from the SD card on my Nook Color since you created the method, and now I'm excited to use your work on my new Nook HD+ (just received yesterday) !
just got mine and got an update notification. turned off wifi so it didnt complete.any word if it breaks root ir bootloader?
CWM is now possible too.
Something is interesting, eventhough mine originally got automatically updated to 2.0.2, but after the factory reset, it went back to 2.0.0. But for some weird reason I can't get root.
Maybe this will help, the build number is 2.0.0.1031.lithium01.ovation.rldp.s68403 with the manufactured date 10/22/2012
please compare mine to your.
I also rewrote your code into a batch file. You can double check it I guess.
Code:
@echo off
cls
@echo .
@echo wait for it
@echo .
adb devices
@echo .
@echo if you do not see you device listed above hit ctrl+c and exit the script
@echo then check adb on your PC and device then try again.
@echo .
@echo reroute /data/local/tmp
adb wait-for-devices shell rm -r /data/local/tmp
adb shell ln -s /data/ /data/local/tmp
@echo .
@echo Now rebooting
@echo .
adb reboot
@echo .
@echo waiting for reboot to finish and making directory /data/su
adb wait-for-devices shell mkdir /data/su
@echo uploading su
adb push su /data/su/
@echo uploading busybox
adb push busybox /data/su/
@echo uploading boot_complete_hoot
adb push boot_complete_hook.txt /data/boot_complete_hook.sh
adb shell chmod 755 /data/boot_complete_hook.sh /data/su/*
@echo .
@echo Now rebooting again
@echo .
adb reboot
@echo .
@echo waiting for reboot to finish and getting shell
adb wait-for-devices shell
someone0 said:
Something is interesting, eventhough mine originally got automatically updated to 2.0.2, but after the factory reset, it went back to 2.0.0. But for some weird reason I can't get root.
Maybe this will help, the build number is 2.0.0.1031.lithium01.ovation.rldp.s68403 with the manufactured date 10/22/2012
please compare mine to your.
I also rewrote your code into a batch file. You can double check it I guess.
Click to expand...
Click to collapse
so, when you run this, after the final adb shell, what are the permissions on /system/xbin/su?
run su and you should get the root prompt.
I don't get root prompt, su never get copied to /system/xbin/su
here is the list of my finding.
Code:
/data/
-rwxr-xr-x shell shell 167 2012-11-10 05:52 boot_complete_hook.sh
/data/su
-rwxr-xr-x shell shell 586212 2012-11-10 06:07 busybox
-rwxr-xr-x shell shell 22364 2012-11-10 06:07 su
/data/local
lrwxrwxrwx shell shell 2012-11-10 06:20 tmp -> /data/
cat boot_complete_hook.sh
#!/system/bin/sh
/data/su/busybox mount /system -o remount,rw
/data/su/busybox cp /data/su/su /system/xbin/su
chown 0.0 /system/xbin/su
everything is in place and correct, but no dice. either boot_complete_hook.sh didn't get executed or it did but never get launched with root permission.
someone0 said:
I don't get root prompt, su never get copied to /system/xbin/su
here is the list of my finding.
Code:
/data/
-rwxr-xr-x shell shell 167 2012-11-10 05:52 boot_complete_hook.sh
/data/su
-rwxr-xr-x shell shell 586212 2012-11-10 06:07 busybox
-rwxr-xr-x shell shell 22364 2012-11-10 06:07 su
/data/local
lrwxrwxrwx shell shell 2012-11-10 06:20 tmp -> /data/
cat boot_complete_hook.sh
#!/system/bin/sh
/data/su/busybox mount /system -o remount,rw
/data/su/busybox cp /data/su/su /system/xbin/su
chown 0.0 /system/xbin/su
everything is in place and correct, but no dice.
Click to expand...
Click to collapse
well, there should be more stuff in the shell file, you miss the final chown line: chmod 06755 /system/xbin/su
It did, I just didn't copy and paste the output correctly. But regardless, since the foulder /system/xbin don't have the su file, this mean as I suspected earlier, either it wasn't executed or lauched w/ root permission.
someone0 said:
It did, I just didn't copy and paste the output correctly. But regardless, since the foulder /system/xbin don't have the su file, this mean as I suspected earlier, either it wasn't executed or lauched w/ root permission.
Click to expand...
Click to collapse
check if your /system/bin/clrbootcount.sh calls /data/boot_complete_hook.sh
verygreen said:
check if your /system/bin/clrbootcount.sh calls /data/boot_complete_hook.sh
Click to expand...
Click to collapse
This is interesting, it look as if it won't launch the /data/boot_complete_hook.sh
Code:
cat /data/boot_complete_hook.sh
#!/system/bin/sh
/data/su/busybox mount /system -o remount,rw
/data/su/busybox cp /data/su/su /system/xbin/su
chown 0.0 /system/xbin/su
chmod 06755 /system/xbin/su
[B][email protected]:/data $ /data/boot_complete_hook.sh
/data/boot_complete_hook.sh
/system/bin/sh: /data/boot_complete_hook.sh: No such file or directory
1|[email protected]:/data $
[/B]
Yub it does
Code:
cat clrbootcount.sh
#!/system/bin/sh
################################################################################
##
#
# File clrbootcount.sh
# Description Clear the bootcount variable to 0 on successful boot
#
##
# Run potential hook first.
[B]/data/boot_complete_hook.sh[/B]
# Zero the boot count
cat /system/etc/zerobootcnt > /bootdata/BootCnt
This guide has been made with and for the i9505, but will most likely also work on other Galaxy S4-models.
Please be extra careful on models other than i9505 as the 'mmcblkXpXX' partition numbers might differ on your device. How to check this is written in the procedure.
As I could not find a procedure in this forum yet, I have made one myself.
Of course all of the below is 'USE AT YOUR OWN RISK'.
Requirements before you start
Install KIES software (and included driver) and connected your S4 atleast once (to see if it works)
Have ADB-executable available. It can be found in the ADT Bundle from Google. There are also much smaller packages with ADB-only which will work. I might create one myself later on and attach it to this thread..
Device is rooted and has busybox-installed (default with motochopper root method). Applications with a similar name in Play Store will allow you to install busybox manually.
Enable developer mode, go to Settings - More - Device-info - Tap 7 times on 'Build number' to unlock 'Developer options' in the previous screen. Then go to 'Developer options' and thick 'USB debugging'
Connect USB cable to your computer and smartphone with 'USB debugging' enabled
Preparations for both backup methods
Now open a ADB-shell, in Windows this would be: 'cmd' in Start-menu (or CTRL+R).
Change the directory to the ADT directory: sdk\platform-tools. In my case:
Code:
cd C:\Android\sdk\platform-tools
Then start the shell using adb:
Code:
adb shell
If you get the error:
'error: device offline'
Then, check your device and allow USB debugging for the presented device. Now try again the command 'adb shell'
If all goes well, you will see the following:
[email protected]:/ $
Now switch to root-user:
Code:
su -
It is possible that the phone now asks you to permit or deny root access. Of course, please permit.
When the switch succeeds, the '$' changes to '#', but you can also verify it by the id-command:
Code:
[email protected]:/ # id
id
uid=0(root) gid=0(root) context=u:r:shell:s0
If it shows root, all is fine.
Then, check with the following command if /efs is available and mounted:
Code:
mount | grep efs
It should show something like:
Code:
mount | grep efs
/dev/block/platform/msm_sdcc.1/by-name/efs /efs ext4 rw,seclabel,nosuid,nodev,no
atime,discard,journal_checksum,journal_async_commit,noauto_da_alloc,errors=panic
,data=ordered 0 0
Backup method using TAR
NOTE: In case you left the ADB shell, please return to it using command 'adb shell' and switch to root again via 'su -' as described above.
Run the folowing command to backup the whole efs-partition (all the files available on the system):
Code:
tar -cvf /data/media/0/efs.tar /efs
Your output will look like this:
Code:
[email protected]:/ # tar -cvf /data/media/0/efs.tar /efs
tar -cvf /data/media/0/efs.tar /efs
tar: removing leading '/' from member names
efs/
efs/imei/
efs/imei/mps_code.dat
efs/wifi/
efs/wifi/.mac.info
efs/FactoryApp/
efs/FactoryApp/test_nv
efs/FactoryApp/hist_nv
efs/FactoryApp/fdata
efs/FactoryApp/serial_no
efs/FactoryApp/factorymode
efs/FactoryApp/keystr
efs/FactoryApp/hw_ver
efs/FactoryApp/baro_delta
efs/FactoryApp/prepay
efs/FactoryApp/earjack_count
efs/FactoryApp/batt_cable_count
efs/bluetooth/
efs/bluetooth/bt_addr
efs/gyro_cal_data
efs/00000000.authtokcont
efs/carrier/
efs/carrier/HiddenMenu
efs/drm/
efs/drm/widevine/
efs/drm/widevine/5dsokxEEDXgQhkN50bp-Z2K5InM_/
efs/drm/widevine/5dsokxEEDXgQhkN50bp-Z2K5InM_/D3qpp0bxmJhbiZwIsCbXJ1434rc_
efs/drm/widevine/5dsokxEEDXgQhkN50bp-Z2K5InM_/RXFABDUxyT6Q+Zwx9ZhPGOq2Bq8_
efs/drm/playready/
efs/drm/playready/00004.PRV
efs/drm/playready/playready0.dat
efs/drm/playready/playready1.dat
efs/drm/playready/playready.hds
efs/wv.keys
efs/log/
efs/log/boot_cause
efs/.files/
efs/.files/.dx1/
efs/.files/.dm33/
efs/.files/.mp301/
efs/ss_data
efs/h2k.dat
efs/hw_offset
This will add all files in /efs to the tar archive located on your internal memory as 'efs.tar'.
Now, the permissions of this tar are incorrect (for this location) so we have to correct them:
Change owner and group:
Code:
chown media_rw:media_rw /data/media/0/efs.tar
And the file permissions:
Code:
chmod 664 /data/media/0/efs.tar
Now, your tar-backup is ready and can be copied via MTP towards your computer or you can use adb to copy it over. First type 'exit' twice to exit the adb shell. CTRL+C is an alternative to leave the 'adb shell'.
Code:
adb pull /mnt/shell/emulated/0/efs.tar .
This will copy the efs.tar to your current directory, which is in my case C:\Android\sdk\platform-tools. You can also replace the last . with the directory where you would like to put the file in.
Backup method using 'dd'
NOTE: In case you left the ADB shell, please return to it using command 'adb shell' and switch to root again via 'su -' as described above.
From the output of the earlier executed command 'mount | grep efs', you can get the path of the EFS partition. It start with '/dev/block/..' is the part which you can use to find the original partition on your device.
As you can see, in my case this is, and I do not expect it to be any different on your device:
/dev/block/platform/msm_sdcc.1/by-name/efs
To check which 'mmcblk' partition it is, we should check out this link:
Code:
ls -al /dev/block/platform/msm_sdcc.1/by-name/efs
This will show you the mmcblk which is the EFS-partition:
Code:
ls -al /dev/block/platform/msm_sdcc.1/by-name/efs
lrwxrwxrwx root root 1970-01-05 23:39 efs -> /dev/block/mmcblk0p10
As you can see, the actual partition in my case is:
Code:
/dev/block/mmcblk0p10
I expect that this is the same for all i9505-devices, but it's better safe to check it. On i9500-devices this might be a different number as they have a different partition-layout, that's why we're checking this. It is very important to save this location, also for future restores.
Now, to backup the partition using dd, run the following command, please make sure that the part directly after 'if=' is the partition you found using the 'ls -l' command. In my case '/dev/block/mmcblk0p10':
Code:
dd if=/dev/block/mmcblk0p10 of=/data/media/0/efs.img
When it finishes, it will show you something like:
Code:
27904+0 records in
27904+0 records out
14286848 bytes transferred in 1.195 secs (11955521 bytes/sec)
This command reads the efs-partition, byte-by-byte to your internal memory, which you can transfer later on to your PC using ADB or MTP.
As the file created is owned by root:root and doesn't have the default permissions used for files at this location, it can be corrected with the following 2 commands:
Change owner and group:
Code:
chown media_rw:media_rw /data/media/0/efs.img
And the file permissions:
Code:
chmod 664 /data/media/0/efs.img
Now, your DD-backup is ready and can be copied via MTP towards your computer or you can use adb to copy it over. First type 'exit' twice to exit the adb shell. CTRL+C is an alternative to leave the 'adb shell'.
Code:
adb pull /mnt/shell/emulated/0/efs.img .
This will copy the efs.img to your current directory, which is in my case C:\Android\sdk\platform-tools. You can also replace the last . with the directory where you would like to put the file in.
To restore the files
Now to restore the files, in case there is really a need to, like imei-number ****up or something with the MAC-address of your wifi, or whatever.. the following commands can be used:
Of course, once again. USE AT YOUR OWN RISK!!!! Do not use this if not really necessary, as there are risks involved in doing this.
To restore the tar-backup, open 'adb shell' and switch to root using 'su -'. Now, first switch to the root directory, which is most likely not needed, but just to make sure the files will be extracted to the right location:
Code:
cd /
Before executing the next command, I assume that you have the efs.tar file in the root-directory of your internal SD-card.
Now, extract the tar file:
Code:
tar -xvf /data/media/0/efs.tar
This will extract the efs.tar file back to it's original location. It will show you something like:
Code:
[email protected]:/ # tar -xvf /data/media/0/efs.tar
tar -xvf /data/media/0/efs.tar
efs/
efs/imei/
efs/imei/mps_code.dat
efs/wifi/
efs/wifi/.mac.info
efs/FactoryApp/
efs/FactoryApp/test_nv
efs/FactoryApp/hist_nv
efs/FactoryApp/fdata
efs/FactoryApp/serial_no
efs/FactoryApp/factorymode
efs/FactoryApp/keystr
efs/FactoryApp/hw_ver
efs/FactoryApp/baro_delta
efs/FactoryApp/prepay
efs/FactoryApp/earjack_count
efs/FactoryApp/batt_cable_count
efs/bluetooth/
efs/bluetooth/bt_addr
efs/gyro_cal_data
efs/00000000.authtokcont
efs/carrier/
efs/carrier/HiddenMenu
efs/drm/
efs/drm/widevine/
efs/drm/widevine/5dsokxEEDXgQhkN50bp-Z2K5InM_/
efs/drm/widevine/5dsokxEEDXgQhkN50bp-Z2K5InM_/D3qpp0bxmJhbiZwIsCbXJ1434rc_
efs/drm/widevine/5dsokxEEDXgQhkN50bp-Z2K5InM_/RXFABDUxyT6Q+Zwx9ZhPGOq2Bq8_
efs/drm/playready/
efs/drm/playready/00004.PRV
efs/drm/playready/playready0.dat
efs/drm/playready/playready1.dat
efs/drm/playready/playready.hds
efs/wv.keys
efs/log/
efs/log/boot_cause
efs/.files/
efs/.files/.dx1/
efs/.files/.dm33/
efs/.files/.mp301/
efs/ss_data
efs/h2k.dat
efs/hw_offset
Then reboot your phone normally and see if it works again as you would expect.
If you restored the TAR-backup succesfully, you do not need to restore the dd-image. But in case your tar did not work or your /efs is not mounted due to corruption (in recovery) you can try the dd-recovery instead.
PLEASE BE AWARE THAT YOU SHOULD BE SURE ABOUT THE LOCATION OF THE EFS-PARTITION. THIS LOCATION WAS FOUND USING the 'ls -al /dev/block/platform/msm_sdcc.1/by-name/efs'-COMMAND EARLIER DESCRIBED. If you do not know this location, there's a risk you are overwriting other partitions (MODEM, SYSTEM, RECOVERY, ETC).
If you are sure about the original location, /dev/block/mmcblk......, then use this path just straight after 'of='. On my device the partition is /dev/block/mmcblk0p10.
Code:
dd if=/data/media/0/efs.img of=/dev/block/mmcblk0p10
Output will be similar to:
Code:
27904+0 records in
27904+0 records out
14286848 bytes transferred in 1.195 secs (11955521 bytes/sec)
This will read the efs.img and put it back in the original location.
NOTE 1: This thread gives you two options of backupping the EFS-partition. It is preferred to do both, better safe than sorry.
NOTE 2: Luckily, I have never had to restore any of the backups myself (not on this phone and not on earlier phones). This means that I was never able to test the restores, which counts for the most of us.
NOTE 3: DO NOT RESTORE unless you are really sure this will solve your issue. This will never resolve any lag or other problems with your rom.
NOTE 4: It is normal that the DD-file is much larger (10MB in size) as it also copies unused space and other meta-data of the partition.
NOTE 5: USE AT YOUR OWN RISK! Although the backup part is nearly riskless.
Note X: Feel free to thank me for this post.
Reservation for second post, just in case.
Isn't rooting and using rootexplorer to zip de efs folder to external SD card and just copying that with a microSD cabel way easier?
johan81 said:
Isn't rooting and using rootexplorer to zip de efs folder to external SD card and just copying that with a microSD cabel way easier?
Click to expand...
Click to collapse
Yes, zipping is easier but you will lose your permissions (owner and file permissions (changed via chown/chmod)) so it is actually not a good backup. The permissions/ownerships are backupped with the tar- and dd-backup.
The dd-file includes more than just the file; it also contains the partition meta-data, in case your filesystem got corrupted and it is not possible to recovery it.
Good job man.
EFS Professional v2.0.35 is now support S4. You can also use this:
http://forum.xda-developers.com/showthread.php?t=1308546
shaq1907 said:
EFS Professional v2.0.35 is now support S4. You can also use this:
http://forum.xda-developers.com/showthread.php?t=1308546
Click to expand...
Click to collapse
dont seem to work crashes out while backing up
working now with new update
anybody knows how to adb read the the entire partition table of the galaxy s4?
A few weeks ago one of my important apps started crashing on open.
Since I have important informaiton saved on that app I need to obtain it.
Is there a way to access that package folder (and that app is not debuggable) with adb or shell?
When I try to access via adb and shell the result it Permission denied.
I can't root the phone, so this is out of the quesiton.
I'm using Google Pixel 1 with Android 10 Build - Build/QP1A.191005.007.A3)
There isn't any way to access /data/data/ as a normal user or shell user, the only user able to access that is root, at least according to the permissions.
You could try to backup using "adb backup package", then you could apply this backup back on another phone or on this same app after reinstalling it.
bystroy said:
A few weeks ago one of my important apps started crashing on open.
Since I have important informaiton saved on that app I need to obtain it.
Is there a way to access that package folder (and that app is not debuggable) with adb or shell?
When I try to access via adb and shell the result it Permission denied.
I can't root the phone, so this is out of the quesiton.
I'm using Google Pixel 1 with Android 10 Build - Build/QP1A.191005.007.A3)
Click to expand...
Click to collapse
Temporarily root phone's Android, means add su cmdlet what is suitable, and then mount the partition in question as RW by means of ADB applying su.
Example:
Code:
adb devices
adb push <SU-BINARY> / data/local/tmp/
adb shell "chmod +x /data/local/tmp/su"
adb shell "/data/local/tmp/su -c 'mount -t auto -o rw,remount <PARTITION-IN-QUESTION>'"
adb pull "<DIRECTORY-TO-PULL>" <LOCATION-ON-PC>
Using a Xiaomi Mi11 (rooted). Recently upgraded to MIUI 13 which is based on Android 12. Was going to do my usual TWRP backup before bringing the phone in to fix some minor problems with sticky volume keys, when I realized (!) my TWRP cannot even mount the /data partition, let alone decrypting and doing any backup.
So I started reading up on TWRP developments, and realized TWRP for now has lost its ability to see anything under /data if your phone is on Android 12.
Never a fan of things like Titanium backup where the backup is done on an app-by-app basis, so a lot of of settings like magisk modules / phone behavior, etc etc cannot be retained (at least that was my impression of it when I briefly tried those solutions). So when I decided to bring my phone in for repair anyway, I went ahead and wiped the phone clean, and had to live with losing 10 day's worth of my data - 10 days because fortunately I did a backup just before I upgraded from MIUI 12 to MIUI 13 10 days ago... (yeah could have done a lot of manual work to salvage some of the data before I wiped it clean, but I didn't bother with the tedious processes).
So I now have a fixed phone, no more sticky buttons, and restored my nandroid backup with the older MIUI 12 system (android 11 based), and not even considering moving back to MIUI 13 until there is a feasible way to do a TOTAL backup of the /data partition, in others words a nandroid backup on Android 12....
Question - is there any feasible method of doing a Nandroid Backup on an Android 12 system, with or without TWRP?
Thank you !!!
A NANDroid-backup is the bitwise 1:1 copy of existing Android system.
If phone's Anndroid OS is rooted then you always can launch a NANDroid-backup.
This can get achieved by pure ADB commands what of course requires ADB is enabled on phone.
xXx yYy said:
A NANDroid-backup is the bitwise 1:1 copy of existing Android system.
If phone's Anndroid OS is rooted then you always can launch a NANDroid-backup.
This can get achieved by pure ADB commands what of course requires ADB is enabled on phone.
Click to expand...
Click to collapse
Could you elaborate?
I can picture this issue -
if you do "adb shell" to enter terminal (or plain adb pull?) while your phone is switched on, a lot of files are being locked and/or being modified while the phone OS is running so how can someone just take a snapshot of everything under /data even with proper adb commands?
And if you go to recovery mode first, well at the present time no TWRP can access the data partition it seems. So again even with the appropriate adb commands, no copying is possible....?
Any clarification appreciated !
You would run
Code:
adb wait-for-device
adb root & adb shell "stop"
adb shell "mount -o rw,remount /data"
: run the backup command here
adb shell "start" & adb unroot
xXx yYy said:
You would run
Code:
adb wait-for-device
adb root & adb shell "stop"
adb shell "mount -o rw,remount /data"
: run the backup command here
adb shell "start" & adb unroot
Click to expand...
Click to collapse
Dear Android export @xXx yYy - wow ! This looks really promising !!
I just did a quick test by going straight to adb shell, "su", then "stop". My phone screen totally went blank, and I was amazed ! This is awesome !!! "start" and after a while the phone boots up again.
I then tried "top" while the phone is stopped. It seems to still have a few android related processes running, so I am not 100% sure if the whole system has been frozen. But you obviously know what you are talking about, and I have faith in you.
(by the way, I cannot "adb root", seems like after doing a quick search I will need to make my phone think it is a development build by patching the adbd daemon first on my phone.. suggestions on what to do appreciated)
You have just made me decide to spend the coming hours to test the following. Let me know if I should skip any of the steps below because you know it works so I don't need to waste time to validate:
1. Do a proper backup with TWRP first in case I screw up anything
2. start a terminal session with adb shell
3. "su", "stop"
4. "cd /data"
5. "tar -cvpzf /data/backup.tar.gz -C /data"
(If no error, this should be my nandroid backup...?)
6. flash phone and wipe everything clean, so it is back to brand new status, non-rooted
7. reboot phone, see if it is starting new as if I have just bought the phone
8. root the phone, then try and "stop", "delete everything under /data except /data/media", "delete everything under /data/media", "copy backup.tar.gz back to /data", "tar -xvzf /data/backup.tar.gz -C /"
9. If phone works and is back to the state immediately before backup, then restore successful
Take note that
Code:
adb root
is giving root access to adb ( adbd - read: adb daemon )
what has nothing to do with giving root access to current Android user with following shell command
Code:
adb shell "su"
Also take note that Android services aren't located in /data partition, the partition you want to back up.
With @xXx yYy 's help I think I am getting somewhere.
So essentially a "stop" command in android will stop Zygote (i.e. the mother of all app processes if I am not mistaken). Once you have stopped Zygote, I believe you are then free to make a duplicate of the entire /data environment.
So far that's exactly what I have done. Created a tar.gz file with a size of around 40GB. I believe I am halfway there in my quest to do Nandroid without TWRP, but what I still need to try is to restore the tar file after factory resetting the phone. Will be a time consuming process (as obviously I will also need to have a tried-and-true real backup created first in case I screw something up... I am doing everything on my main phone that I actually use everyday), so I will continue my experiment in the coming days.
One question I have already encountered however - I still cannot do "adb root", which would have allowed me to directly create the backup tar file AND pipe it to my PC all in one go. So far I have had to tar all within the phone, which means space will be a constraint, and it is more time consuming creating the backup file THEN think of a way to transfer that file out of the phone. Already posted a question here asking for help, and if anyone knows of a good way to get adbd to grant adb root request, please let me know.
Above all else, once I have a working method, and I have polished the process, I will be happy to share. I suspect many others are also yearning for a good backup / restore procedure on Android 12.
one can't backup /data partition this way, because tar is just a toybox applet not cabable of preserving secontext. get a gnu tar binary (for example from opengapps installer), set mount namespaces to global, set selinux permissive (if kernel allows it, important) and run from su
/storage/1234-5678 is exFAT and has enough free disk space
Code:
tar --selinux --xattrs --numeric-owner -vcpPf /storage/1234-5678/data.tar /data
/storage/1234-5678 is vfat or less free disk space
Code:
tar --selinux --xattrs --numeric-owner -vcpP /data | gzip | split -a 1 -b 1024m - /storage/1234-5678/data.tar.gz.
another approach would be loop mount some file and busybox cp -avc everything where the -c flag is responsible for secontext (proper busybox required)
--numeric-owner flag is recommended if you are planning to extract it on linux PC later
you could also exec-out straight to PC if no MicroSD Card available, but requires gzip or other compressed stream, otherwise windows will mess up linefeed with carriage return and render your file unreadable
Code:
adb exec-out "su -c 'tar --selinux --xattrs --numeric-owner -vcpP /data | gzip'" > data.tar.gz
restoring .tar.gz from TWRP is absolutely possible, it's just that TWRP can't handle encrypted userdata partition (yet)
Code:
cat /external_sd/data.tar.gz.* | gzip -d | tar --selinux --xattrs -vxpPC /
(where tar must called with full path to binary like /cache/tar or /tmp/tar, or unlink /sbin/tar applet and place binary /sbin, or just rename it gtar)
Note: bitwise 1:1 copy of apps is not possible/sufficient if you factory reset your device, because apps might save data in TEE TrustZone (which is flushed on factory reset)
Hi @seemebreakthis, very interesting discussion on Android 12 backup!
Did you reach a workable solution with this?
Since we can restore most apps from a Google backup, it seems the real issue is to recover the user settings etc. after the Google restore.
Interested in this. Any success thus far?
aIecxs said:
one can't backup /data partition this way, because tar is just a toybox applet not cabable of preserving secontext. get a gnu tar binary (for example from opengapps installer), set mount namespaces to global, set selinux permissive (if kernel allows it, important) and run from su
/storage/1234-5678 is exFAT and has enough free disk space
Code:
tar --selinux --xattrs --numeric-owner -vcpPf /storage/1234-5678/data.tar /data
/storage/1234-5678 is vfat or less free disk space
Code:
tar --selinux --xattrs --numeric-owner -vcpP /data | gzip | split -a 1 -b 1024m - /storage/1234-5678/data.tar.gz.
another approach would be loop mount some file and busybox cp -avc everything where the -c flag is responsible for secontext (proper busybox required)
--numeric-owner flag is recommended if you are planning to extract it on linux PC later
you could also exec-out straight to PC if no MicroSD Card available, but requires gzip or other compressed stream, otherwise windows will mess up linefeed with carriage return and render your file unreadable
Code:
adb exec-out "su -c 'tar --selinux --xattrs --numeric-owner -vcpP /data | gzip'" > data.tar.gz
restoring .tar.gz from TWRP is absolutely possible, it's just that TWRP can't handle encrypted userdata partition (yet)
Code:
cat /external_sd/data.tar.gz.* | gzip -d | tar --selinux --xattrs -vxpPC /
(where tar must called with full path to binary like /cache/tar or /tmp/tar, or unlink /sbin/tar applet and place binary /sbin, or just rename it gtar)
Note: bitwise 1:1 copy of apps is not possible/sufficient if you factory reset your device, because apps might save data in TEE TrustZone (which is flushed on factory reset)
Click to expand...
Click to collapse
You are a genius! That's excactly what i was searching for! Thank you!
This is a bit beyond me.. though I'm looking for a full ROM backup on Android 12. Does this work?
TWRP 3.7.0 is for Android 12 including Encryption Support (except for Samsung)