Hi guys!!!
I have a rooted first generation Pixel running stock Android 10. I would like to take a physical image of the device using ADB.
If I command "mount" in ADB shell, I get for example the following line:
/dev/block/sda35 on /data type ext4
If I image /dev/block/sda35 with dd and netcat, I get an image but the file based encryption comes in the way and the files are useless.
So if I would like to take a clear text (physical) image of this device, what should I image? Or maybe the other way of asking this is, what is the best image I can expect through ADB with root privileges?
Thanks!!!
Any particular reason you don't want to backup through TWRP?
The main reason is that I am interested to know how this is done manually through ADB.
I am also interested how the file based encryption works and what kind of information I can get out from the device with a best possible image.
So for me this is only an experiment, I dont have any valuable data on the device
dd allows you to get a bit-perfect copy of the partition. You are seeing the contents exactly as they are. For Android to view the actual files (well, those that are encrypted, not necessarily everything is encrypted with FBE) it has to decrypt them, which requires the key. Additionally, as you can have multiple users on a device, each of the user's files have a separate key.
In the old days of encrypted partitions, there was a metadata partition or similar that you could get the key from. Under FBE, I'm not sure how to do it, but the principle would be similar. So the only way to get a clear text copy of the files using dd is to decrypt.
Do have any knowledge how Android does this decryption in practise?
When I imaged /dev/block/sda, which should be the ”raw” memory device, my phone was open (passcode was entered to gain access to the phone) and the device remained in this state through the imaging.
Still this raw device is FBE, as I would expect actually. So Android does the decryption somehow to the mounted partition, but I dont know how.
Actually I can see that my root directory / comes from a device /dev/root, but in ADB shell I cannot find this device.
Maybe the next thing I will try is to use ADB when my phone is booted to TWRP and TWRP does the decryption...
In any case, Thanks for your answer!
I don't know the details, but one key point about decrypting is that it does not change the actual content on disk. Think of decrypting as a translation service. There is something on disk you want to read, so the translator turns it into the plain text view. Similarly if you want to store some data, the translation service converts it into the encrypted view to be stored on disk. This is all done as the files are requested, and is transparent to any app. (Otherwise if you decrypted the disk and 'pulled the plug', you could go in and get the plain text content, which would defeat the purpose of encryption).
So doing this in TWRP won't make any difference.
Related
I'm assuming that "unlocking" is not talking about a carrier lock. I got my Xoom a few days ago. It's my first Android device although I did play with Honeycomb on the ultra slow emulator with the SDK. I also have some Unix/Linux background but am VERY rusty but I think I get it now...
So, does unlocking mean giving us the ability to remount the system partition in RW (read/write) mode?
Also, I see Beagleboy has been able to extract the boot and system partitions (but had to trash his recovery partition to do so). Is this similar to ripping a data CD image in Linux by outputting the "cat" (or "dd"?) of a device (/dev item) to a file? In our case, it looks like items beginning with "/dev/block/mmcblk". I used "mount" to see how the system and userdata partitions were mapped. Just followed the symbolic links in "/dev/block/platform/sdhci-tegra.3/by-name" to figure out boot and recovery.
Simply unlocking (without rooting) doesn't affect anything, does it? I mean, the userdata partition is left as-is, right? Meaning I could back up my Xoom by extracting that? And could I simply use "adb pull" directly on the device to rip my userdata? And would I have to remount it in RO first?
Sorry for all the questions. I'm not ready to unlock until Motorola decides to release the Xoom Wi-Fi (MZ604) image files.
unlocking the bootloader allows you to run custom kernels - so if you know what a bootloader is from linux...
pretty much allows new functionality, ie SD card to be run
But the SD card functionality isn't there until you run that custom kernel, right? Just unlocking the Xoom by itself doesn't change it's functionality, right? Except for the bootloader part I mean.
I won't have root, but could I use adb to remount system as RW? Even if I don't have permissions to write to it without root? I'll have to give these a try later.
Right now, I just want to back up my userdata (and virtual SD card).
Anyone know what /dev/fuse is?
An unlocked device gets you nothing out of the box. You still have to be root to remount system as rw.
Gotcha. But that's enough to reflash the boot and system partitions, right?
Hello,
I am trying to recover from a softbrick issue. I have a BLU Studio C 5+5 LTE and therefore can't use TWRP or CWM (At least that is my assumption, maybe someone knows different). Before getting into the softbrick state I took 3 different types of backups in the hopes that one of them could be used in case it was needed. (like this)
Type 1 - I did an ADB shell backup from a completely stock device (unrooted) I used this command-
adb backup -apk -all -f fullbackup.adb
For this method I followed this guide here-
https://linuxiswonderful.wordpress.com/2015/04/04/full-backup-of-nonrooted-android/
Type 2 - I used Titanium backup and performed a complete system and application backup
Type 3 - I rooted the phone and backed up all partitions using dd after reviewing the partition layout of the device. For example, to backup the system partition I did the following at an ADB shell-
dd if=/dev/block/mmcblk0p21 of=/storage/sdcard1/firmware-img/system.img
I believe the last operation I tried before softbricking was installing the Xposed framework module for my device (running Lollipop 5.1.1).
I am able to still communicate to my device using ADB and I can get an ADB shell. or enter fastboot mode My device presently shows the manufacturer's logo when booting and gets no further.
To recover from this issue I think I have two basic options
#1 restore from backup
#2 locate the problem that is causing the system to hang at startup in the first place
At the end of the day I am trying to find the simplest, quickest method to get back up and running. Both methods are acceptable to me. I am not worried about losing any data.
My challenge/sticking point is how to turn my backups into a usable format to get me back on track or understand the boot process enough to get out of the boot loop.
The first thing I tried was mounting my raw image files created from the dd process. I followed this guide-
https://samindaw.wordpress.com/2012/03/21/mounting-a-file-as-a-file-system-in-linux/
I ran these commands-
#losetup /dev/loop0 /path/to/my/system.img
# mkfs -t ext3 -m 1 -v /dev/loop0
# mount -t ext3 /dev/loop0 /mnt
# cd /mnt
# ls
The various image files I created all seemed to mount "ok" OK meaning that the loopback mount process worked but it appears there is nothing but a lost+found folder in the mounted image. (I'm not sure why that is.)
I am still researching methods to turn my other backups into something usable for recovery purposes.
For using the adb backup file I created, this is what my understanding is-
Adb backup uses a type of compression (don’t remember what kind). I would need to uncompress the file first. After uncompressing and being able to view the file contents I would think I should be able to put together a flashable zip file of some sort.
I think the process for Titanium backup would generally be the same- uncompress/convert file format, create/assemble a flashable zip file
The last thought I had was trying to get the system to boot. To do so, I need to better understand the boot process. I am familiar with how Linux boots as I am a Sys Admin. I know Android is similar but just different enough to make me research this further. I can pull dmesg log for anyone if that will help. I was also seeing where you could use the logcat command. (That is new to me as it seems more Android specific and not used in Linux that I know of)
If there is any other info you need to see, please let me know. I made a lot of notes about the system architecture, partition layout, etc.
Many thanks in advance for your help!
XDA Visitor said:
Hello,
I am trying to recover from a softbrick issue. I have a BLU Studio C 5+5 LTE and therefore can't use TWRP or CWM (At least that is my assumption, maybe someone knows different). Before getting into the softbrick state I took 3 different types of backups in the hopes that one of them could be used in case it was needed. (like this)
Type 1 - I did an ADB shell backup from a completely stock device (unrooted) I used this command-
adb backup -apk -all -f fullbackup.adb
For this method I followed this guide here-
https://linuxiswonderful.wordpress.com/2015/04/04/full-backup-of-nonrooted-android/
Type 2 - I used Titanium backup and performed a complete system and application backup
Type 3 - I rooted the phone and backed up all partitions using dd after reviewing the partition layout of the device. For example, to backup the system partition I did the following at an ADB shell-
dd if=/dev/block/mmcblk0p21 of=/storage/sdcard1/firmware-img/system.img
I believe the last operation I tried before softbricking was installing the Xposed framework module for my device (running Lollipop 5.1.1).
I am able to still communicate to my device using ADB and I can get an ADB shell. or enter fastboot mode My device presently shows the manufacturer's logo when booting and gets no further.
To recover from this issue I think I have two basic options
#1 restore from backup
#2 locate the problem that is causing the system to hang at startup in the first place
At the end of the day I am trying to find the simplest, quickest method to get back up and running. Both methods are acceptable to me. I am not worried about losing any data.
My challenge/sticking point is how to turn my backups into a usable format to get me back on track or understand the boot process enough to get out of the boot loop.
The first thing I tried was mounting my raw image files created from the dd process. I followed this guide-
https://samindaw.wordpress.com/2012/03/21/mounting-a-file-as-a-file-system-in-linux/
I ran these commands-
#losetup /dev/loop0 /path/to/my/system.img
# mkfs -t ext3 -m 1 -v /dev/loop0
# mount -t ext3 /dev/loop0 /mnt
# cd /mnt
# ls
The various image files I created all seemed to mount "ok" OK meaning that the loopback mount process worked but it appears there is nothing but a lost+found folder in the mounted image. (I'm not sure why that is.)
I am still researching methods to turn my other backups into something usable for recovery purposes.
For using the adb backup file I created, this is what my understanding is-
Adb backup uses a type of compression (don’t remember what kind). I would need to uncompress the file first. After uncompressing and being able to view the file contents I would think I should be able to put together a flashable zip file of some sort.
I think the process for Titanium backup would generally be the same- uncompress/convert file format, create/assemble a flashable zip file
The last thought I had was trying to get the system to boot. To do so, I need to better understand the boot process. I am familiar with how Linux boots as I am a Sys Admin. I know Android is similar but just different enough to make me research this further. I can pull dmesg log for anyone if that will help. I was also seeing where you could use the logcat command. (That is new to me as it seems more Android specific and not used in Linux that I know of)
If there is any other info you need to see, please let me know. I made a lot of notes about the system architecture, partition layout, etc.
Many thanks in advance for your help!
Click to expand...
Click to collapse
Greetings,
Thank you for using XDA Assist.
There are no specific forums for your device model on XDA. However, if you create an XDA account, you can ask your questions here:
Android Q&A, Help & Troubleshooting
You will receive expert advice there.
Good luck and welcome to XDA!
Hi. I have to flash a TWRP backup and can't do it thorugh custom recovery due I have a Yotaphone (the phone with a LCD screen by one side and a eInk screen by the other side) and the LCD screen is broken, so I have to use fastboot or adb (as far I know). I cannot even install a ROM because it needs the LCD screen for the first start.
The question if I can do it, cause I know it could be problems with formats.
(I asked this on Yotaphone specific xda forum but no one answered)
Thanks
eReader Fan said:
Hi. I have to flash a TWRP backup and can't do it thorugh custom recovery due I have a Yotaphone (the phone with a LCD screen by one side and a eInk screen by the other side) and the LCD screen is broken, so I have to use fastboot or adb (as far I know). I cannot even install a ROM because it needs the LCD screen for the first start.
The question if I can do it, cause I know it could be problems with formats.
(I asked this on Yotaphone specific xda forum but no one answered)
Thanks
Click to expand...
Click to collapse
You would probably have better luck flashing the stock firmware or have someone with the same device create an adb backup then restore it via adb.
Or if you know which individual .img files you need, have them pull a copy of whichever individual .img files you need(for example: system, boot, etc) then fastboot flash them or use adb shell to dd the .imgs back onto your device in the partitions they belong in.
I DO NOT PROVIDE HELP IN PM, KEEP IT IN THE THREADS WHERE EVERYONE CAN SHARE
@Droidriven ,you are right about it would be easy to fash a stock rom, but the LCD screen is necessary for that due the first boot. Maybe I am a little lucky 'cause I live with person who has the same device as me.
I tried the adb backup -all but it seems to just make a backup of the personal data.
Making a dd backup patition would be the better, but for some reason my device isn't recognized as a MTP device and can only connect in PTP. Tried to change the configuration on the phone but still only works with PTP, and I think in PTP mode doesn't have a mounted folder where I can make this stuff.
What I don't know how to do is the dd within the adb shell. It will work connected in PTP mode?
eReader Fan said:
@Droidriven ,you are right about it would be easy to fash a stock rom, but the LCD screen is necessary for that due the first boot. Maybe I am a little lucky 'cause I live with person who has the same device as me.
I tried the adb backup -all but it seems to just make a backup of the personal data.
Making a dd backup patition would be the better, but for some reason my device isn't recognized as a MTP device and can only connect in PTP. Tried to change the configuration on the phone but still only works with PTP, and I think in PTP mode doesn't have a mounted folder where I can make this stuff.
What I don't know how to do is the dd within the adb shell. It will work connected in PTP mode?
Click to expand...
Click to collapse
Is USB debugging enabled?
I DO NOT PROVIDE HELP IN PM, KEEP IT IN THE THREADS WHERE EVERYONE CAN SHARE
Yes, debuggind mode is on. In PTP mode, adb sees my device correctly, in MTP mode appears like ???????
I think maybe the answer is where that you mentioned about "adb shell". As long as I can't see the phone mounted in MTP mode it's the only way I see. Now I am searching for the way on pointing the dd output file outside the adb shell. So the process is:
BACKUP:
-adb shell > dd partitions saving them outside the phone
FLASHING:
-fastboot partition by partition
Another problem I have is to know which partion is each, 'cause with "mount" I don't get so much information and with "cat /proc/partitions" only have 13 partitions with their size and no more info. I am looking what to "adb push" that can help me. Maybe install busybox.
Trying to backup&restore without MTP, without access to the recovery nor SDcard... Harder is impossible!!!
eReader Fan said:
I think maybe the answer is where that you mentioned about "adb shell". As long as I can't see the phone mounted in MTP mode it's the only way I see. Now I am searching for the way on pointing the dd output file outside the adb shell. So the process is:
BACKUP:
-adb shell > dd partitions saving them outside the phone
FLASHING:
-fastboot partition by partition
Another problem I have is to know which partion is each, 'cause with "mount" I don't get so much information and with "cat /proc/partitions" only have 13 partitions with their size and no more info. I am looking what to "adb push" that can help me. Maybe install busybox.
Trying to backup&restore without MTP, without access to the recovery nor SDcard... Harder is impossible!!!
Click to expand...
Click to collapse
This command in adb shell or Terminal Emulator should give you your partitions and names(obviously you'd type "su" then press enter then run this command)
ls -l /dev/block/platform/msm_sdcc.1/by-name/
The part with "msm.sdcc.1" might be different for your device. If that command doesn't work I'll help you find what needs to go in that part of the command for your device.
I DO NOT PROVIDE HELP IN PM, KEEP IT IN THE THREADS WHERE EVERYONE CAN SHARE
su is not found inside the adb shell, and I found this is cause is not rooted. I have to do it through TWRP in android 6.
As I said, I have two devices of my model so I hope I find time tomorrow for doing it. I also hope to can flashing it to the other device in fastboot mode or some way it doesn't need the main screen (remember I have a LCD screen and a eInk)
I will say something when I do the root. Thanks
Finally did it!
It appears each partitions clearly with the "ls" command you give to me. The question now is how to dd outside the phone. Have I to mount the pc inside the shell or what?
eReader Fan said:
Finally did it!
It appears each partitions clearly with the "ls" command you give to me. The question now is how to dd outside the phone. Have I to mount the pc inside the shell or what?
Click to expand...
Click to collapse
adb shell should work to dd, you just need to make absolutely certain that you are dd-ing the correct .img to the correct partition(mmcblk0xx), the partition number would go where the xx is.
For example, my recovery.img would be flashed to mmcblk018(the number of my recovery partition.
If you dd an .img to the wrong partition, you'll brick the device, the command has to be exactly correct, no margin for error or easy fix if you get it wrong.
I DO NOT PROVIDE HELP IN PM, KEEP IT IN THE THREADS WHERE EVERYONE CAN SHARE
I know all this stuff, but first I need to make the .img of each partition, and I though with adb shell I could do a dd to outside the phone. The TWRP backup I have isn't .img files, they are .win files.
I searched again if its possible to do that and all I found is the xda thread about doing a workaround with adb forward and busybox. If there is no more options I will do that.
What I thought to do is create a backup of the needed partitions and save them in the userdata free space. I think this have to be possible, but as I cannot use the LCD screen I have to do the backup where I do not have to pass thorugh the first boot configuration, cause it is did in the LCD screen. Which partitions have I to backup? Only system and boot? Or there is another tool for creating .img backups?
EDIT: Also found the twrp adb possibilities (http://www.pocketables.com/2014/10/using-twrps-new-adb-interface.html) but have the same problems than with dd
I frequently modify boot and recovery partitions from within terminal app. Here's what I do to grab the boot partition for example(you likely want BusyBox installed first)
cat /dev/block/bootdevice/by-name/boot >boot.img
or
dd if=/dev/block/bootdevice/by-name/boot of=boot.img
Make changes, then reverse the commands to write back. I think cat gives you a more verbatim copy for initially cloning a partition. I have had success with both.
The question that brought me here is what happens if i flash all partitions from a firmware archive and attempt to upgrade a whole system this way from twrp recovery.....
This works fine on my phone. If it doesn't work on yours, standard disclaimer applies about bricking, phone exploding, etc... that's all on you.
The problem has been that regardless of patches and regardless of methods to make the stock 8.1 data partition readable from TWRP, my phone won't do it. So as follows is how I've backup up and restored as an alternative. I don't know if this works well on Windows (Probably not) or MacOS (More likely it will), so its only tested on Linux.
Install adb on the computer
On the running phone, enable usb debugging.
Connect to the phone, allow the computer to access it.
Get a shell
Code:
adb shell
Enter as follows to find the block device where data is mounted
Code:
mount | grep /data | grep block
My output was this
Code:
/dev/block/mmcblk0p24 on /data type ext4 (rw,seclabel,nosuid,nodev,noatime,discard,journal_checksum,journal_async_commit,noauto_da_alloc,errors=panic,data=ordered
The first part, "/dev/block/mmcblk0p24" is what I was interested in. You can see it's mounted at /data
You're in fact looking for this specifically at the beginning "/dev/block/mmcblk0p24 on /data"
If you're confused or you have multiple mount-points or what not, or you don't understand, Stop Now, you're about to screw things up.
Copy the first part of what you have here, in my case "/dev/block/mmcblk0p24" (don't use quotes though)
Reboot into TWRP.
Make sure /data is not mounted in the TWRP menu. If it is, then no need to do this as you can back it up directly from TWRP anyway, and you don't nee this.
Backup will make an image of the entire partition, so it will be big. As follows to backup, change the /dev/block/xxxxxxx to what yours is, if it is differant. Replace xxxxxxx with what your output was, mine was mmcblk0p24 (this needs to be input correctly for backup and restore, this here is where you can screw your phone up)
Code:
adb shell 'dd if=/dev/block/xxxxxxx' > DataBackupName.img
(Above, you DO use the single quotes)
DataBackupName.img can be named whatever you want to call it.
This takes a long time, my phone writes 12 gigs or so.
The above command should exit telling you how much data was written. You don't want to have an incomplete backup because the usb cable wasn't great or the process spit the dummy for some reason.
To restore, cross your fingers (works fine on my PC)
Also from TWRP and also making sure data is not mounted:
Code:
adb push DataBackupName.img /dev/block/xxxxxxx
You need to have the correct text to replace the xxxxxx. Screwing this up is very high risk of bricking your phone.
Okay all that said, my assumption is that the initial dump won't work on Windows as it needs to direct the output to a file and I have a hunch that the syntax above for directing the output might be done differently. If someone knows how to do the backup on Windows, or can clarify if it works or not as is (after testing) I imagine that would be helpful for Windows users. Feedback in general is good for others, solutions to problems are great.
Additionally, when I was looking for this solution, the answers were a bit old and had to be mildly adapted, but there was a complaint back then that adb couldn't handle the restore. That hasn't been the case for me. A more recent adb binary might fix this if you happen to have this sort of problem.
A benefit of this method, is that if your system can mount an ext4 volume, you can also mount the image, so if you only want one file from a previous backup, or you want to remove a file from the image, or add one, that's all possible... with Linux (Linux geeks know who they are). Note that the image also contains the contents of what gets mounted at /storage/emulated/0
You can compress the image file when its done to reduce the size.
What this is: it's a shell script that generates commands for TWRP using its Open Recovery Script (ORS) language. See: https://twrp.me/faq/openrecoveryscript.html
Over the years I've found that I repeatedly did the same set of actions in TWRP, with just file names changing. Being inherently lazy I decided to automate these processes. So now I simply do the following in a Terminal session on my phone:
To backup my current rom: . bf
To backup my current rom and update my current rom (flash over the current rom) which is sort of like an OTA update: .bf -o
To NOT backup my current rom, restore a previous backup, and clean update the rom (wipe system, flash updated rom, Gapps, and Magisk): .bf -brf
To do a backup and clean install (wipe data and system) a rom: . bf -c
The script generates the ORS commands in /cache/recovery/openrecoveryscript and reboots the phone into recovery. TWRP will automatically process the file and, if there are no errors, reboot the system.
Requirements:
- the script must run as root (for access to /cache)
- flashed files must all be in a single directory (/sdcard/@install) and adhere to the following naming conventions:
File names (no spaces):
rom-*.zip
gapps-*.zip
kernel-*.zip (if flashed after Magisk)
Kernel-*.zip (if flashed before Magisk)
MyMods-*.zip (regular mod)
MyTemp-*.zip (one-off mod/fix)
su-*.zip (Magisk or other root installer)
Note: there must only be one file of each these types in the folder, if required. I normally prefix files that I'm not using with an x to avoid multiples, for example I'll have rom-lineage-17.1-20200223* and xrom-lineage-17.1-20200205* in the directory
- a system property (my.version) must be set as it's used to name new backups. I used to add the property to build.prop (using a MyMods zip) but now I use a Magisk MyMods module.
- two additional scripts (depending on the options chosen) are needed to be called in TWRP and must exist in /sdcard/Tools. They are:
rmpwd (remove the lock screen password after restoring a backup)
wipesys (wipes /system or /system_root because TWRP lost the 'wipe system' command - but not 'wipe data' - in version 3)
Limitations:
I've only used it on A-only systems. I have no idea if it works on A/B.
Design notes:
- this is not an executable script because files in /sdcard can't be. But I wanted it (and all my other scripts) in /sdcard so that it is easily accessible. That's why there are no exit statements (only returns) in it as it's run in-line using ". bf" or "source bf".
Usage notes:
- I recommend adding the directory to $PATH (export PATH=$PATH:/sdcard/Tools)
- many of the options (for example b,p,m,s,...) are toggles (on/off switches). They can easily be "flipped" by adding them to the command options. For example, -b is on by default, so specifying it again (. bf -b) turns it off (. bf -bb would leave it on).
- the -v option caters for the transition from one Android version to another. It makes it possible to have a sub-directory with the new version files (gapps, rom, mods), yet using the same su version. For example, if I'm currently on Android 9 but want to test Android 10, then I'd create a directory under /sdcard/@install called 10 (or Q or whatever). then I could switch from my current rom to a new 10 rom (clean install) on using .bf -cv 10 and the script will look in /sdcard/@install/10 for the gapps, mods, and rom. Always specify the -v option last in the list or separately (. bf -...v 10 or . bf -... -v 10).
Reserved.
Sent from my OnePlus 3T using XDA Labs
Thank you very much for sharing your scripts and ideas. I did not even know that there is a chance to script TWRP . My motivation to start my Android Backup and Restore Tools project were very similar to yours ... beside as I am on a Pixel 3a with A/B-system and not having TWRP available (yet(?)) I was looking for a way to do the backup and restore process without TWRP at all.
In addition I prefer transferring the data directly to a remote device. The storage on the devices is always limited and having a backup on the device itself (even if it is only for a limited time period) may cause trouble or at least limits the possible size of the backup which can be done.
Ideal for me would be a method to extract the important components of a ROM (/system, /vendor, /data, ...) off of the device and package them later in a way that they can be flashed back to the device later on e.g. using fastboot. As the new devices go into the direction of userspace fastboot (fastbootd) I am wondering if there would we the chance to "enhance" the fastbootd mode in a way that it can be used as a kind of recovery mode, too.
I am going off topic and just sharing my dreams only ... nevertheless thank you again for sharing!
AndDiSa said:
Thank you very much for sharing your scripts and ideas. I did not even know that there is a chance to script TWRP . My motivation to start my Android Backup and Restore Tools project were very similar to yours ... beside as I am on a Pixel 3a with A/B-system and not having TWRP available (yet(?)) I was looking for a way to do the backup and restore process without TWRP at all.
In addition I prefer transferring the data directly to a remote device. The storage on the devices is always limited and having a backup on the device itself (even if it is only for a limited time period) may cause trouble or at least limits the possible size of the backup which can be done.
Ideal for me would be a method to extract the important components of a ROM (/system, /vendor, /data, ...) off of the device and package them later in a way that they can be flashed back to the device later on e.g. using fastboot. As the new devices go into the direction of userspace fastboot (fastbootd) I am wondering if there would we the chance to "enhance" the fastbootd mode in a way that it can be used as a kind of recovery mode, too.
I am going off topic and just sharing my dreams only ... nevertheless thank you again for sharing!
Click to expand...
Click to collapse
Thanks for your post. I find it interesting how different requirements produce very different solutions.
One of my main drivers is to do everything on the device itself and avoid using a PC if at all possible.
Sent from my OnePlus 3T using XDA Labs
BillGoss said:
What this is: it's a shell script that generates commands for TWRP using its Open Recovery Script (ORS) language. See: https://twrp.me/faq/openrecoveryscript.html
Click to expand...
Click to collapse
Interesting project, thanks.. TWRP on my a/b device (OP7) doesn't show options to backup system or vendor partitions, just the images. Do you happen to know if ORS supports image backup?
Tirofog said:
Interesting project, thanks.. TWRP on my a/b device (OP7) doesn't show options to backup system or vendor partitions, just the images. Do you happen to know if ORS supports image backup?
Click to expand...
Click to collapse
Unfortunately ORS doesn't do images. See the documentation at https://twrp.me/faq/openrecoveryscript.html
Sent from my OnePlus 3T using XDA Labs
@BillGoss Hello, your script shows that it must be possible what I am looking for although that is quite different from what your script provides.
I have two rooted phones with LineageOS based ROMs that don't fully shutdown. If I shut them down from the system they drain the battery more than while in use. Therefore I must first reboot them to recovery and from there shut them down.
I am looking for a script that does exactly that: after being started in system mode reboot to recovery and then poweroff.
I have little knowledge in scripting and thus don't understand your script to reduce it to the requested commands.
Could you, please, help me with such a script?
bege10 said:
@BillGoss Hello, your script shows that it must be possible what I am looking for although that is quite different from what your script provides.
I have two rooted phones with LineageOS based ROMs that don't fully shutdown. If I shut them down from the system they drain the battery more than while in use. Therefore I must first reboot them to recovery and from there shut them down.
I am looking for a script that does exactly that: after being started in system mode reboot to recovery and then poweroff.
I have little knowledge in scripting and thus don't understand your script to reduce it to the requested commands.
Could you, please, help me with such a script?
Click to expand...
Click to collapse
Have you tried just running /system/bin/reboot -p in a Terminal session? That should shutdown your phone.
To do it through TWRP:
Create a file called openrecoveryscript containing the following command cmd reboot -p
Copy the file to /cache/recovery and reboot into recovery.
You can look at the finalize function in my script for how to create your own script to do this.
BillGoss said:
Have you tried just running /system/bin/reboot -p in a Terminal session? That should shutdown your phone.
To do it through TWRP:
Create a file called openrecoveryscript containing the following command cmd reboot -p
Copy the file to /cache/recovery and reboot into recovery.
You can look at the finalize function in my script for how to create your own script to do this.
Click to expand...
Click to collapse
Thank you for your help.
I tried everything to solve the incomplete poweroff issue, but on one phone it is a known issue in the LineageOS ROM, on the other phone it is an unsolved issue related to Magisk.
Poweroff in TWRP with a openrecoveryscript works without cmd in your answer.
When the phone reboots to TWRP I must decrypt the data partition before the script runs. This is not necessary to just poweroff the phone and an OTA update starts running right away.
What does an OTA update do differently when it reboots to TWRP? What must I do to skip the password screen in TWRP when an openrecoveryscript is in /cache/recovery ?
An ota doesn't use a recovery script. It uses a different way of invoking TWRP. I never liked into it.
You'll need to see if a Los developer can explain to you exactly how an ota works.
BillGoss said:
An ota doesn't use a recovery script. It uses a different way of invoking TWRP. I never liked into it.
You'll need to see if a Los developer can explain to you exactly how an ota works.
Click to expand...
Click to collapse
Meanwhile I noticed that this behavior is only on my A/B device where the OTA update is not installed by a TWRP script but before rebooting already. The other, older device is no A/B device and there TWRP starts with the openrecoveryscript right away. But that device is not encrypted. So I am not sure whether it is the standard behavior or due to the fact that is not encrypted.
Do you use your script on an A/B device? Is your phone encrypted? How does TWRP behave?
bege10 said:
Meanwhile I noticed that this behavior is only on my A/B device where the OTA update is not installed by a TWRP script but before rebooting already. The other, older device is no A/B device and there TWRP starts with the openrecoveryscript right away. But that device is not encrypted. So I am not sure whether it is the standard behavior or due to the fact that is not encrypted.
Do you use your script on an A/B device? Is your phone encrypted? How does TWRP behave?
Click to expand...
Click to collapse
Yes, I use my script on my A/B phone. I always run my phone's encrypted. And the behaviour of TWRP is the same as on A-only.
But note that I never used the Los ota updates. I've always downloaded the updates manually then used my script to backup and install.
I don't use TWRP for ota updates on my A/B phone because they are designed to run on a running system.
BillGoss said:
Yes, I use my script on my A/B phone. I always run my phone's encrypted. And the behaviour of TWRP is the same as on A-only.
But note that I never used the Los ota updates. I've always downloaded the updates manually then used my script to backup and install.
I don't use TWRP for ota updates on my A/B phone because they are designed to run on a running system.
Click to expand...
Click to collapse
Do you need to enter your password/pattern before your script runs in TWRP? Even if you e.g. only run a system backup that does not need decrypted data?
Well I suppose decryption is needed as soon as TWRP wants to mount an encrypted file system. So if e.g. the /etc/fstab of the initial ramdisk (which is used by the kernel when booting TWRP) contains a mount point with a an encypted filesystem TWRP will automatically ask for the key ...
bege10 said:
Do you need to enter your password/pattern before your script runs in TWRP? Even if you e.g. only run a system backup that does not need decrypted data?
Click to expand...
Click to collapse
Yes, I do: the backup is written to internal storage which is encrypted. Also, /cache is actually /data/cache on my A/B phone so the storage needs to be decrypted for TWRP to read the ORS.
BillGoss said:
Yes, I do: the backup is written to internal storage which is encrypted. Also, /cache is actually /data/cache on my A/B phone so the storage needs to be decrypted for TWRP to read the ORS.
Click to expand...
Click to collapse
OK, thank you, then I understand how it works and that I cannot bypass decryption for my workaround for the shutdown issues. I hoped to make it less laborious.
@BillGoss Hello, I once more need your help.
Inspired by your script I tried a simple openrecoveryscript to backup with TWRP.
When I put this line from your script (reduced)
Code:
backup BD `date +%y%m%d-%H%M%S`
into openrecoveryscript I get the error
Backup name: '`date' contains invalid characters: '`date'
Click to expand...
Click to collapse
(translated from German)
A similar problem occurs when I try to set variables: When the script is running it uses any text after the variable name literally as a string. Backticks, quotes, using "cmd" don't change anything.
And using a variable as backup name throws
Backup name: '$name' contains invalid characters: '$name'
Click to expand...
Click to collapse
In the TWRP terminal setting and using variables works as expected.
Does this still work for you? Do you have an idea why using the date command and variables in an ORS doesn't work here?
I use TWRP 3.6.0_9.0 on Fairphone 3, /e/OS (based on LineageOS for microG, Android 10)
bege10 said:
@BillGoss Hello, I once more need your help.
Inspired by your script I tried a simple openrecoveryscript to backup with TWRP.
When I put this line from your script (reduced)
Code:
backup BD `date +%y%m%d-%H%M%S`
into openrecoveryscript I get the error
(translated from German)
A similar problem occurs when I try to set variables: When the script is running it uses any text after the variable name literally as a string. Backticks, quotes, using "cmd" don't change anything.
And using a variable as backup name throws
In the TWRP terminal setting and using variables works as expected.
Does this still work for you? Do you have an idea why using the date command and variables doesn't work here?
I use TWRP 3.6.0_9.0 on Fairphone 3, /e/OS (based on LineageOS for microG, Android 10)
Click to expand...
Click to collapse
As you've discovered an ORS is not a Bash script and, therefore, you cannot do things like set variables or use inline commands with `...`. It is processed, I believe, by the "twrp" program inside TWRP.
You could, in the TWRP terminal, run
Code:
twrp backup BD `date +%y%m%d-%H%M%S`
If you want to run a shell command in ORS you base to write cmd <shell command> where <shell command> is the actual command.
But what you should be doing is running a shell script on your phone that produces an ORS file which doesn't need to access the shell environment. That's what my bf script is.
Thank you for your quick answer.
Oh no! I didn't realize that your bf script does not write the commands in backticks and the variables into the ORS but their values.
Thank you very much.
In case other ORS noobs like me come around and only want a simple script for regular backup and shutdown I post my solution here.
The bash script ORS_backup_shutdown.sh that creates the openrecoveryscript (this script is part of a Tasker task that afterwards copies and renames the file to /cache/recovery/openrecoveryscript and reboots to recovery):
Code:
scr=/sdcard/Documents/Z/ORS/ORS_backup_shutdown
echo > $scr # initialise ors
slot=`getprop ro.boot.slot_suffix` #active slot for A/B device
dat=`date +%F`
tim=`date +%H-%M-%S`
nam=$dat"--"$tim"_e_FP3-db"$slot # adapted from the default backup name of TWRP
echo set tw_storage_path external_sd >>$scr # internal SD = sdcard
echo backup bdmo $nam >>$scr # m = skip digest, o = compress
echo reboot poweroff >>$scr
And the openrecoveryscript outcome:
Code:
set tw_storage_path external_sd
backup bdmo 2022-05-09--09-18-02_e_FP3-db_b
reboot poweroff