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
Related
DISCLAIMER
This project may brick you phone. Use at your own risk.
What's New in v3
I don't quiet understand SELinux, so the v2 did not process SELinux contexts while restoring "system", "data" and "cache" partitions. Now v3 fix it. If you'd ever restored them by v2, run v3 sub-menu "Tools"->"Restore SELinux security contexts" to fix it.
Add backup boot.img and "sdcard/Android/data".
Add "Wipe Dalvik cache".
Add functionality to fix common boot-loop problems including "Switch runtime to Dalvik from Art", "Disable Xposed", and "Fix build.prop permission".
What's New in v2
The major functionality added from v1 is to support nandroid backup/restore for "system", "data" and "cache" partitions to/from internal sdcard by using the supplied "ea-menu" shell script.
The "ea-menu" also support partition management such as mount, unmout, ro and rw.
Background
This is a project for developers who need a quick fixing and nandroid backup/restore environment for LG-D838 that still cannot install custom recovery currently. If you want to test, hack or modify system apks and/or Xposed modules but are afraid of bricking, you may try this project. Without this project, although you can recover the phone by flashing official firmware, reconstructing user settings and data is time-consuming. Normal ADB might be a solution for fixing, but you may not have enough time to fix problems before system hang up or goes into boot loop. And normal ADB cannot do nandroid backup/restore.
The Early-ADB sits in the early stage of Linux init process, right after "/system" mounted, far before Android stuffs starting. This way keeps the Early-ADB alive even if the Android stuffs such as apks or jars crash. Therefore, you can fix problems of Android stuffs by ADB through PC console.
The newly added backup/restore functions make it easier to backup and restore /system, /data and /cache partition with archive format compatible with CWM recovery.
More Information
See post #2 for more background information. And welcome to provide any technical information for FURTHER DEVELOPMENT section in post #2.
How It Works
The project hijacks e2fsck to interrupt Linux init process and redirect to its custom ADB daemon, the Early-ADB, so that you can access ADB by PC console in the early stage if required. The hijack concept comes from 2nd-init and Safestrap. While installing this project, the installer backup original e2fsck and replace it with a script. On each boot up, this script determine to go for original e2fsck as normal boot or go for Early-ADB by checking the Volume-Up key.
Basic Q&A
See post #3 for basic Q&A.
Installation
Make sure you have backup your user data. Make sure your D838 is rooted. Make sure you have turned on USB Debugging option in your D838.
Prepare Windows ADB utility. Currently the Early-ADB installer script is only for Windows command prompt.
Download "EarlyADB.v1.zip" in the download link below, and extract it into the Windows ADB folder. Please do not process the extracted "packs.zip". Keep it unchange.
Connect the D838 phone to your Windows PC through USB cable.
In your Windows PC, open a command prompt and "cd" to your ADB directory. Type "install" to run the Early-ADB installer.
Uninstallation
Walk through the same steps as above Installation 1 to 4.
In your Windows PC, open a command prompt and "cd" to your ADB directory. Type "unins" to run the Early-ADB uninstaller.
How To Use
Power on or reboot your D838.
When you see LG logo, press and hold Volume-Up key. After seeing the screen dims obviously, you can release the Volume-Up key. Now early-ADB daemon is running and Linux init is hold.
Connect D838 to any PC with adb through USB cable.
By using adb shell, run "ea-menu" to backup/restore to/fram internal sdcard, or fix problems manually.
To leave Early-ADB daemon, press and hold power button for at least 8 seconds to reboot the phone.
The internal sdcard is not a safe place for nandroid backup files. Remember to copy them to external sdcard.
Limitations And Known Issues
Only "/system", "/data" and "/cache" are mounted. Manually mount other partitions if required.
The Early-ADB daemon sits in early init stage that many services are not ready to use and some normal adb functionalities cannot work. For examples, you cannot reboot by software commands. You cannot get model name from getprop command. However, you can "push" and "pull" files and access "/system" and "/data" to fix many crash problems.
Don't expect this project as a brick protection. If you destory bootloader, this project can do nothing.
Don't do OTA upgrade. Any system files modification may (or may not, it depends) result in brick.
The Google Music media files are prevented from backup by Early-ADB. Backup them by yourself, otherwise if you recover data partition, you will lose them.
Download
v3: EarlyADB.v3.zip
v2: EarlyADB.v2.zip, obstacle due to SELinux problem. Download it only for research purpose.
v1: EarlyADB.v1.zip, mirror
eladbd daemon source: eladb_mod.zip, modified from https://source.android.com/source/downloading.html branch android-4.4.2_r2, only modified part is included in the zip.
Changelog
v3 (2014/05/21)
BUGFIX: Restore SELinux security contexts if restoring /system, /data or /cache partition.
Add backup/restore kernel (boot.img)
Add backup/restore /sdcard/Android/data contents
Add Tools sub-menu to "Wipe Dalvik cache".
In Tools sub-menu, add fix to common boot-loop problems including "Switch runtime to Dalvik from Art", "Disable Xposed" and "Fix build.prop permission".
In Tools sub-menu, add fix to v2 bug "Restore SELinux security contexts".
Reduce package size by minimizing installer busybox.
Auto mount partitions for backup/restore operations.
Ask user to confirm restore operation.
v2 (2014/05/18)
Run early then v1, right after /system mounted.
Default mount system, data and cache partitions.
Add "ea-menu" to run from adb shell, so you can do nandroid backup/restore for system, data and cache partitions.
Introduce new "SAFE" mount concept by mounting partitions in non-standard /mnt/system, /mnt/data, and /mnt/cache to prevent from accessing accidentally by other unknown background services while restoring.
Build busybox from source code 1.22.1 (source available from http://www.busybox.net)
Build pigz 2.3.1 for using by nandroid backup/restore (source available from http://zlib.net/pigz/)
Build static verion of mksh, so that in SAFE mount we don't have to rely on system partition for shell. (source available from https://source.android.com/source/downloading.html branch android-4.4.2_r2 )
v1 (2014/05/11)
Initial testing release
Thanks
Savoca of directing me to Safestrap and 2nd-init concepts
Hashcode with Safestrap project for concept of hijacking e2fsck
XDA:DevDB Information
Early-ADB, Tool/Utility for the LG G Pro 2
Contributors
pcfree
Version Information
Status: Testing
Created 2014-05-11
Last Updated 2014-05-21
Somthing about this project
HISTORY FOR DEVELOPING THIS PROJECT
After hacking the TOT file format to root D838 with ioroot (see my post [Tutorial] How to root D838 that cannot enter recovery mode), I start thinking of customizing my phone. Without custom recovery, it make me uncomfortable to hack system apks or try out Xposed. This leads to my first attempt.
1st Attempt -- Porting Loki-Friendly aboot.img
Initially, I want to port loki-friendly D802 JellyBean aboot.img to D838. If it successes, we would have custom recovery, custom kernel and custom ROM. Choosing D802 is because they use the same QualComm S800 chip and both com from LG. I studied the bootloader chain and tried to make lokified stock kernel with the help from xda Recognized Developer Savoca. I found the possibly best solution would be install D802 JB aboot.img and laf.img into D838 with a lokified custom-made rebuilt D838 stock kernel. However, I cannot make sure if my phone will survive from brick if the testing is failed.
If D838 KK sbl1.img (1st secondary bootloader) cannot accept D802 JB aboot.img, the phone will enter bulk device mode which can be recovered from brick in Linux PC. On the other hand, if D802 aboot.img is accepted to run but hang up due to other issues, the thing becomes more complicated. My D838 is for my daily work use. Without a backup phone, I am not ready to try the concept. The project is not dead yet, but pending now.
2nd Attempt -- 2ndrec
Savoca also direct me to Safestrap project. As new to Android dev, it is complex for me to port such a job. However, I think it may be possible to run a recovery environment by 2nd-init. Some attemptions were made to port D802 ramdisk of cwm recovery by 2nd-init without success, then I try to study my own "2ndrec" without 2nd-init. I want to make a modified recovery-like program to be injected into Linux init process. Without understanding of displaying things to the framebuffer, I pending this project too.
3rd Attempt -- Early-ADB
As eager to have a fix/recovery environment, I start to focus on adbd (adb daemon). I've found it is much easier to run adbd if I can prepare the basic environment for it and rebuild a custom adbd without unnecessary check. And this the project here.
FURTHER DEVELOPMENTS
You are welcome to provide information for the following subjects
Manually Mount Internal SDCARD
In normal environment (means non-Early-ADB), internal sdcard is a virtual device which is mapped by fuse from "/data/media/0" directory. I don't know if it is a good idea, but you may do the following commands to link it by yourself in adb shell for Early-ADB.
mount -o remount,rw rootfs
rm /sdcard
ln -s /data/media/0 /sdcard
The side effect for the soft link method is all files/dirs created would be root owned. This is different from uid 1023 (media_rw) created by fuse. However, this may not be a problem because in noraml environment fuse oversides all permissions. It means after reboot you can still get full access of all files on fuse mapped virtual sdcard.
Starting from Early-ADB v2, it is not recommanded to link sdcard because SAFE mount makes the internal sdcard path vary.
If you want to do thing such as manually backup "/data" contents to "/sdcard", remember to exclude "/data/media/0" because "/sdcard " is linked to "/data" contents. This is not a problem for "ea-menu" script because it automatically excludes virtual internal sdcard.
Manually Mount External SDCARD
You are welcome to provide information on how to manually mount D838 external sdcard. I know the exact block device of external sdcard is "/dev/block/mmcblk1p1". However, direct mount command does not succeed for my exfat sdcard. If we can mount external sdcard, we can do thing much more for Early-ADB. For example, we can backup and restore "/system" and "/data" partition as custom recovery does. For newer un-rootable stock firmware, you may build custom stock system.img by injecting "su" and "Early-ADB" first, then install it by this project.
Basic Q&A
Can I use Early-ADB to install apks or run adb backup/restore command?
Better not to try. I have not tried it yet. However, many system services do not start up yet. You will probably fail to do these works.
Can I use adb push/pull command to exchange files?
Yes.
Is the Early-ADB daemon rooted?
Yes, the Early-ADB daemon runs as root. After installed, it does not rely on "su" binary. Even if your "su" is deleted suddently, you can use Early-ADB to push it back.
Can I do OTA update after installing Early-ADB?
No, never try it. It depends on OTA update script and update contents, but you never know. Any "/system" partition modification may cause OTA fail if the modified files are in the OTA update list. However, currently we cannot modify bootloader stacks, usually we can flash stock firmware to recover from OTA fail.
By using Early-ADB, you have many ways to manually upgrade stock firmware while keeping root. Since Early-ADB v2, a custom nandroid compatible stock firmware files is also a solution.
May I use the Early-ADB for F350 series G Pro 2?
Some parameters are reterieved from D838. It may or may not works with F350 series. Try at your own risk. Use "install -f" and "unins -f" instead in the last step of installation and uninstallation procedures.
How to use "ea-menu" shell script?
Use "adb shell" to connect to your phone in Early-ADB mode. Then type "ea-menu" to run it. It is a menu-driven script and not too hard to learn how to use it.
Why is the internal sdcard not a safe place to keep nandroid backup files?
The internal sdcard is a fuse device located on data partition. If you do factory reset, you will lose these backup files too. Keep them on external sdcard or other place for safety.
good post, thanks
Early-ADB now upgrades to v2. Now you can use it to do nandroid backup and restore for "system", "data", and "cache" partitions to/from internal sdcard. Thus it may be more useful than just fixing.
With the backup/restore function, you may also safely upgrade to future stock firmware by making custom nandroid archive files from stock firmware while keeping root and Early-ADB.
Release v3. This release includes one bugfix and several improvements:
BUGFIX: In v2, while restoring "system", "data" or "cache" partitions, SELinux security contexts are not processed. Now v3 fix it. If you've ever used v2 to restore partitions, you'd better use v3 new Tools sub-menu => "Restore SELinux security contexts" to fix it. The backup archive files created by v2 are still ok, but you have to use v3 to restore them.
IMPROVEMENTS:
Add backup/restore kernel (boot.img)
Add backup/restore /sdcard/Android/data contents
Add "Wipe Dalvik cache" in Tools sub-menu.
In Tools sub-menu, add fix to common boot-loop problems including "Switch runtime to Dalvik from Art", "Disable Xposed" and "Fix build.prop permission".
Reduce package size by minimizing installer busybox (rebuild).
Auto mount partitions required for backup/restore operations.
Ask user to confirm restore operation.
Hello, so can this make a FULL backup? And a full restore? Essentially using your pc as the recovery?
How to Uninstall Early ADB?
Please help me uninstall EarlyADB so that I can boot into CWM Philz Touch Recovery.
SOLVED
Thanks.!
glasseffects said:
Please help me uninstall EarlyADB so that I can boot into CWM Philz Touch Recovery.
SOLVED
Thanks.!
Click to expand...
Click to collapse
@glasseffects, please, write how you solved your problem?
--==||==--
WySwiftKey'owane i wyTapatalk'owane z mojego LG G Pro Drugiego Wspaniałego.
--==--
Swiftkeyed and Taptalked from my Great LG G Pro The Second
==
TomeG2kc aka Tomasz G.
TomeG2kc said:
@glasseffects, please, write how you solved your problem?
Click to expand...
Click to collapse
That's fairly simple. Follow the post-installation steps to enter the Early-ADB as described in the first post:
1. Power on or reboot your D838.
2. When you see LG logo, press and hold Volume-Up key. After seeing the screen dims obviously, you can release the Volume-Up key. Now early-ADB daemon is running and Linux init is hold.
3. Connect D838 to any PC with adb through USB cable.
Now from the same folder from which you installed Early-ADB, run "unins.bat".
That's it, the Early-ADB system is uninstalled.
Hope this helps.
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!
android-backup-project
The android backup project provides a set of scripts and tools to backup and/or restore applications installed on Android devices.
This is not adb backup which didn't work for my requirements as
it doesn't backup applications if those are requesting not to be backed up
it does not support restoring to different devices quite well
Google warns that it might be discontinued in future versions of Android
Motivation
I never was really happy about the possibilities to backup / restore Android devices. Especially when you are developing with (different) Android devices, you wish you were able to transfer "configurations" from one device to a different one. Or you would like to revert to an older version of an app or ...
The same is valid when you change your "main" device. The Google mechanism to set up a new device from another one or from a backup works quite well, but has almost the same deficits as adb backup: it doesn't restore all of your apps and data.
Also TWRP or other custom recovery implementation do not really help to get out of this situation. It's fine for creating a backup and restoring it later on the same device but there is no support for switching devices. In addition Android often changes architecture so that TWRP support for a specific device is not guaranteed and at the time of writing there is not even TWRP support for Android 10 yet.
There is another very interesting project related to backup and migration on XDA (https://forum.xda-developers.com/android/apps-games/app-migrate-custom-rom-migration-tool-t3862763). Unfortunately it relays on TWRP, too, and has still some issues to be solved.
Last but not least there is Titanium Backup which is available for a very long time now. It works quite well but the free version is very limited in functionality and provides only the possibility to store the backup on the device itself which is a kind of contradiction for a backup.
Some time ago I started already a similar project (https://github.com/AndDiSa/ART) to manage backup and restore of Android devices remotely. Unfortunately it never finished and due to architectural changes of Android it would need a complete workover so that I decided to start over from scratch
Precondition
adb installed and in execution path
Ubuntu Linux (other should work, too)
a rooted Android device (either by adbd unsecure or by e.g. Magisk / SuperSU)
Usage
Theses scripts kind of do that TiBackup is doing, but controlling the backup- and restore process remotely.
backup_apps.sh
./backup_apps.sh [--system-apps]
This script creates a backup of all user (and system) applications and their data. The backup files will be stored in a directory newly created named by the device and the current date.
restore_apps.sh
./restore_apps.sh [<directory_name>]
Ths script restores the apps and their data of a previous backup created by backup_apps.sh Either the directory is identified automatically by the device connected and the current date or you can pass a directory name as parameter. In that case all the apps and data found in the given directory will be restored.
If you want to restore only a part of them, please copy them into a different directory and give that directory as a parameter to the script.
Important
Keep in mind that restoring all apps may cause issues as some have unique IDs that end up causing problems if you use the same unique ID on different devices.
You also may want to consider only restoring apps that are missing from google play or apps that sadly decide to prevent backups of their (i.e. your) data.
full-backup.sh
./full-backup.sh [--data-backup][--no-data-backup][--media-backup][--no-media-backup][--image-backup][--no-image-backup]
This script does a full backup of (different parts of) the /data partition. There are several options to control the behaviour.
--data-backup will backup /data without /data/media and /data/mediadrm
--media-backup will backup /data/media and data/mediadrm
--image-backup will backup the whole partition which is mounted as /data as a 1:1 copy
As it cannot be guaranteed that during the backup process there will be no single modification on the /data partition it's quite common to get a checksum validation failure after the backup is finished.
full-restore.sh
./full-restore.sh [--data-backup][--no-data-backup][--media-backup][--no-media-backup][--image-backup][--no-image-backup] <directory_name>
This script is restoring data previously created by full-backup.sh It accepts the same parameters as full-backup.sh and takes in addition the name of the directory from where the backup shall be restored.
Important
Be very careful in unsing this method, especially when you are restoring /data It will overwrite everything on the /data partition and this may cause major issues up to the point that your device becomes no longer usable. In that case you probably need to do a full wipe to get it working again.
restore-single-partition.sh
./restore-single-partition.sh <path-to-image-to-be-restored> <name-of-the-partition-on-device>
This script is restoring a single partition image previously created by backup-partitions.sh back to the device. The image can be either in compressed or plain format. As parameters you need to give the path to the partition image and the name of the partition as is is configured on the device (see: /dev/block/by-name/<name>).
Important
This command is in experimental state and may be very dangerous as it can fully brick your device. Be very careful in using this method, you have been warned(!).
Downloads:
android-backup-project-v2.1.zip (md5: b0c71d602963696f7c372d3c2222ae75)
android-backup-project-v2.0.zip (md5: 14be02aa3e2a458ba7d7456dc152dad8)
android-backup-project-v1.6.zip (md5: 00f8dc8630b63fe1398ea61a436c2a0f)
android-backup-project-v1.5.zip (md5: 9cb1183d385f854c1f4b7858855cde58)
android-backup-project-v1.4.zip (md5: 9ad78f33a86e117a72058a336b34ab28)
android-backup-project-v1.3.1.zip (md5: 737a7d3483d98616f650d51eea033619)
android-backup-project-v1.3.zip (md5: 3bb11d4da02754a82f8614a53aacd4df)
android-backup-project-v1.2.zip (md5: 27f365663a97b3c7451938d24ffb7779)
android-backup-project-v1.1.zip (md5: c9806edb32b68109c2fc8e087927ac7a)
android-backup-project-v1.zip (md5: b754cf72fe10c89cdb8e4cb8e94f9e0a)
Special thanks
Credit goes to Raphael Moll who initiated a similar project some time ago and Marc Merlin who improved it to work with Android O. I took some ideas and inspiration from these projects and from my first trial I started years ago. The current implementation does not have much in common with neither of those versions.
Especially I would like to thank @topjohnwu for his great Magisk project and @osm0sis for his great collection of scripts and tools.
XDA:DevDB Information
Android Backup Project, Tool/Utility for all devices (see above for details)
Contributors
AndDiSa
Source Code: https://github.com/AndDiSa/android_backup_project/
Version Information
Status: Stable
Current Stable Version: V1.0
Stable Release Date: 2019-12-08
Created 2019-12-08
Last Updated 2020-01-19
Missing Permissions
Magisk Canary in combination with newer Android versions are restricting permissions even on rooted devices more and more. Due to that not all actions required to do a backup / restore are allowed any longer. To circumvent this restrictions there is a new Magisk Module available which enhances the permissions so that the backup / restore scripts are working.
If you are observing permission issues using the backup / restore scripts please install the AndroidBackupRestore Module in Magisk.
Edit: Latest Magisk Canary (>=20425) is working again without the need for additional changes
Reserved
I there and thanks for the work.
I tried to use your script and I am stuck at "Checking root access"
I am using Magisk. Shell is autorized in #Superuser.
In command line "su" is working see #
Here is my terminal screen
[email protected]~
$ bash full-backup.sh --data-backup --media-backup --image-backup
~/busybox-ndk ~
Déjà à jour.
~
Waiting for device...
Devices detected:
List of devices attached
da279704 device
Checking for root access...
[email protected]~
$ adb shell
gemini:/ $ su
gemini:/ #
Click to expand...
Click to collapse
@cocolol What Android version / device are you using? I did my tests with e.g. a Magisk rooted Pixel 3a on Android 10 without any issues.
Can you try from your command line the following:
adb shell su root -c whoami
and if this is blocked the following:
adb shell su root whoami
probably for your device / configuration
adb shell su whoami
is working
updated to version 1.1 as there was a quote mismatch in one of the scripts
Can you backup and restore just user apps?
str8str said:
Can you backup and restore just user apps?
Click to expand...
Click to collapse
If you use backup_apps.sh without passing the --system-apps option ... but on Android 10 most likely you will still backup (some) system apps. If there is need for that one could add a filter ...
@andisa thank you for your prompt reply and sorry for my late answer
I updated script to 1.1 and still be blocked.
Thus "adb shell su root -c whoami" is working answer is "root"
But other commands didn't work (see log below)
My aim is to jump from PE 9 to PE 10 on xiaomi MI5 and MI8 (dipper) with all my apps.
I came here from Migrate app forum which is not working for me since it is TWRP dependend.
[email protected] ~
$ bash full-backup.sh --data-backup --media-backup --image-backup
~/busybox-ndk ~
Déjà à jour.
~
Waiting for device...
Devices detected:
List of devices attached
da279704 device
Checking for root access...
[email protected] ~
$ adb shell su root -c whoami
root
[email protected] ~
$ adb shell su root whoami
[email protected] ~
$ adb shell su whoami
Click to expand...
Click to collapse
@cocolol ok, that's just as it should be, i.e. if you are rooted with Magisk
adb shell su root -c
prefix should work. Question is: why it is blocked within the script.
Edit: I expect that the script is blocked while checking a sane /data partition. Can you try to remove that part from the script? It doesn't harm and we can prove that my expectations are correct. It's sufficient the remove / comment out the checkForCleanData line.
I got an error: "Unrecognised architecture armv7l".
After adding that to line 82 in functions.sh (and switching flaky usb port) it went through.
Edit:
Device gohan (BQ Aquaris X5 plus)
OS LineageOS 14.1-20191115 (unofficial)
Host Manjaro, bash v5.0.11 (ah well, I had to install PV command)
Edit: fixed device name
Keule-T said:
I got an error: "Unrecognised architecture armv7l".
After adding that to line 82 in functions.sh (and switching flaky usb port) it went through.
Edit:
Device gohan (BQ Aquaris X5 Pro)
OS LineageOS 14.1-20191115 (unofficial)
Host Manjaro, bash v5.0.11 (ah well, I had to install PV command)
Click to expand...
Click to collapse
@Keule-T Thank you very much for the info. I'll add that this change into the next version.
Would be great if others could report issues / success, too, so we can improve the scripts to be able to run on (almost) every device.
AndDiSa said:
Would be great if others could report issues / success, too, so we can improve the scripts to be able to run on (almost) every device.
Click to expand...
Click to collapse
Well, that was a disturbing experience. I downloaded and un-zipped the v1.1 on Arch Linux, opened a terminal from within that extracted folder, and ran the command ./backup_apps.sh with no additional arguments.
The terminal reported this:
Checking for root access...
Determining architecture...
Pushing busybox to device...
busybox-ndk/busybox-arm64: 1 file pushed. 26.0 MB/s (1478208 bytes in 0.054s)
### Creating dir qcom_2019-12-21_QQ1C.191205.016.A1
~/Downloads/android-backup-project-v1.1/qcom_2019-12-21_QQ1C.191205.016.A1 ~/Downloads/android-backup-project-v1.1
Then the terminal listed about 70 lines of .apk files, and then disaster happened. These are the last few lines of what the terminal reported:
## Stop Runtime
## Pull apps
package:/data/app/com.touchtype.swiftkey-80xpz-vz5Aii7U6vdFVHnQ==/base.apk=com.touchtype.swiftkey
/data/app/com.touchtype.swiftkey-80xpz-vz5Aii7U6vdFVHnQ==/base.apk
/data/app/com.touchtype.swiftkey-80xpz-vz5Aii7U6vdFVHnQ==
com.touchtype.swiftkey
./backup_apps.sh: line 55: pv: command not found
Then after that, complete silence. I mean COMPLETE. My phone did a Force Close and powered off. Wouldn't reboot back into system, just looped. I had to do a a Nandroid restore to get back into my phone again. Not good....
OnePlus 3T rooted with Magisk 20.1 and running MSM Xtended XQ v4.0 Android Q rom.
I like the concept, but I think I'll wait until you get it a bit more developed before I do a beta test again... Maybe you can make use of the above information to further your project.
---------- Post added at 12:12 PM ---------- Previous post was at 12:11 PM ----------
Forgot to add that the only thing that made it into the directory your script created on my PC was a file named
app_com.touchtype.swiftkey.tar.gz with a filesize of 0 . That's all that was there.
@Oblias thank you very much for your report. I am very sorry for the mess but it's exactly those reports which help really a lot.
pv is a program which helps logging the communication between the device and the pc and I did not have in mind that it probably is not installed on a Unix system. I'll add a check for the presence of the important programs so that there is a stable basis before starting the scripts.
The normal behaviour of the script is as follows:
- shutdown runtime (to prevent modifications during the backup process)
- backup apps and data
- restart runtime
So a "warm" restart of the device is normal after the backup script finishes. I am only wondering why you had to restore a nandroid ...
AndDiSa said:
@Oblias thank you very much for your report. I am very sorry for the mess but it's exactly those reports which help really a lot.
pv is a program which helps logging the communication between the device and the pc and I did not have in mind that it probably is not installed on a Unix system. I'll add a check for the presence of the important programs so that there is a stable basis before starting the scripts.
The normal behaviour of the script is as follows:
- shutdown runtime (to prevent modifications during the backup process)
- backup apps and data
- restart runtime
So a "warm" restart of the device is normal after the backup script finishes. I am only wondering why you had to restore a nandroid ...
Click to expand...
Click to collapse
Well, you said in the OP that one of the things needed for these scripts to run was to have "Ubuntu Linux (other should work, too)" installed. Arch Linux and Ubuntu Linux both use the Linux kernel, so I thought that would be alright. Which leaves me a bit confused as to why you said that PV is not installed on a Unix system??? But anyways.......
As far as the normal warm restart is concerned, perhaps something got messed up in the command when the script halted?? I'm not all that good with scripts, so I don't know. Also, perhaps whatever made the phone do a poweroff instead of a reboot, also corrupted some system file? Just guessing, of course... But it's not biggie really. Anyone who tries anything like this had better have a backup on hand, just in case any sort of unpredictable event happens.
So, let me know about the PV command issue, and I'll give it another try, if you'd like.
---------- Post added at 01:27 PM ---------- Previous post was at 01:24 PM ----------
Also, as an added thought, when you get a chance, perhaps a small FAQ in the OP as to what the normal behavior is when running these scripts. For example, letting folks know that their phone will do a reboot on the script completion, and things of that nature.... Just a thought....
---------- Post added at 01:31 PM ---------- Previous post was at 01:27 PM ----------
UPDATE: I also just checked my repos, and pv is available to be installed, it just wasn't installed during a 'normal' install of Arch Linux (if there is such a thing).
So, if I install pv, are there any other commands I should check for to see if I have installed before trying the script again?
@Oblias beside those "normal" programs like git, tar, gzip, ... which are normally always installed there is no additional program needed. But nevertheless I agree that probably some additional compatibility checks should be done especially as there are different versions of the programs existing which take probably also different parameters ...
AndDiSa said:
@Oblias beside those "normal" programs like git, tar, gzip, ... which are normally always installed there is no additional program needed. But nevertheless I agree that probably some additional compatibility checks should be done especially as there are different versions of the programs existing which take probably also different parameters ...
Click to expand...
Click to collapse
Makes sense. Alright then, I'll wait until you check things out, and once you have posted back, I'll give it another try. I don't mind some beta testing..
AndDiSa said:
@cocolol
Edit: I expect that the script is blocked while checking a sane /data partition. Can you try to remove that part from the script? It doesn't harm and we can prove that my expectations are correct. It's sufficient the remove / comment out the checkForCleanData line.
Click to expand...
Click to collapse
After some investigation script was blocked on line 29 of functions.sh file on this condition "if [[ $($AMAGISK whoami) == "root" ]]"
I dont know why since when I replace this line with "$AMAGISK whoami" I get "root" as answer
Thus I replace "checkRootType" directly with "AS=$AMAGISK"
But I get the same with next function
Determining architecture...
Unrecognized architecture aarch64
Click to expand...
Click to collapse
Seems to be does'nt get the answers same as problem above
I am using cygwin maybe it come from this.
I replaced == with =~ and it works but for the case condition I found nothing
@cocolol I suppose cygwin has some issues with evaluating the expressions as aarch64 is supported. Probably also here you need to change the comparison ... If you know the type, you can also execute the code for the matching architecture.
Uploaded version 1.2 of the tool with the following improvements:
- support for armv7l architecture
- checking prerequisites needed by the tool, e.g. adb, pv, ...
Hi guys,
Here, for those who are interested, I'm maintaining the packages to use postmarketOS on bare-metal hardware.
I only tested the A750FN variant.
Check it out!
Feedbacks are welcome!
Many thanks:
@VDavid003 for kernel sources
Thanks alot for making this contribution
M0Rf30 said:
Hi guys,
Here, for those who are interested, I'm maintaining the packages to use postmarketOS on bare-metal hardware.
I only tested the A750FN variant.
Check it out!
Feedbacks are welcome!
Many thanks:
@VDavid003 for kernel sources
Click to expand...
Click to collapse
After a week or 2 i can get back home and test it , so keep making these and I'll test them and tell you about my experience
Hello, can you share how you did it? I can't find any files for flashing on the postmarketos wiki page, I have TWRP installed.
Arm1nas said:
Hello, can you share how you did it? I can't find any files for flashing on the postmarketos wiki page, I have TWRP installed.
Click to expand...
Click to collapse
I haven't tested it yet , but you'll have to use the pmbootstrap tool to build a zip that you can flash through the TWRP
The wiki of postmarketOS explains how to use the pmbootstrap tool. Go check it out
animegamer4422 said:
I haven't tested it yet , but you'll have to use the pmbootstrap tool to build a zip that you can flash through the TWRP
The wiki of postmarketOS explains how to use the pmbootstrap tool. Go check it out
Click to expand...
Click to collapse
I figured it out. I created an Ubuntu VM and built it. I am not sure why but now the phone doesn't boot to pmOS, it just spits out some errors or there is only a terminal. TWRP says it can't mount /system, maybe I have to reflash the recovery.
Arm1nas said:
I figured it out. I created an Ubuntu VM and built it. I am not sure why but now the phone doesn't boot to pmOS, it just spits out some errors or there is only a terminal. TWRP says it can't mount /system, maybe I have to reflash the recovery.
Click to expand...
Click to collapse
I don't think it's a issue with the recovery and also it's normal for TWRP to not be able to mount the system
Let's try to diagnose it by going through the error
Could you upload the log and also the screenshot of the error that it spits out
Also upload the built image to some cloud service and send the link here so that i don't have to go through and build the image again
Thanks for testing it out and I'll join you soon so keep trying and I'll try to do everything i can to help you , Have a good day.
animegamer4422 said:
I don't think it's a issue with the recovery and also it's normal for TWRP to not be able to mount the system
Let's try to diagnose it by going through the error
Could you upload the log and also the screenshot of the error that it spits out
Also upload the built image to some cloud service and send the link here so that i don't have to go through and build the image again
Thanks for testing it out and I'll join you soon so keep trying and I'll try to do everything i can to help you , Have a good day.
Click to expand...
Click to collapse
pmos-samsung-a7y18lte.zip
drive.google.com
I think that it's trying to install itself to /system partition which is very small, and the "data" partition is like 50GB. Maybe it's a problem with PBRP (I can't install twrp, it doesn't work for me).
Can you try installing this file and testing if it works for you, or is it the same problem?
Arm1nas said:
pmos-samsung-a7y18lte.zip
drive.google.com
I think that it's trying to install itself to /system partition which is very small, and the "data" partition is like 50GB. Maybe it's a problem with PBRP (I can't install twrp, it doesn't work for me).
Can you try installing this file and testing if it works for you, or is it the same problem?
Click to expand...
Click to collapse
I'd love to test it , but currently I'm not at my home and my A7 is at home (since It's not my daily driver) but I'll test it as soon as I can get back home
Until then
Keep figuring out things
Also I think you can use the TWRP terminal to Change the size of system partition using the resize2fs command i guess
I found this when I looked into it
First to clarify, Resize Partition is different than Resize File System, TWRP provides latter option. It resizes the ext2/3/4 filesystem to the size of partition it's created on. Filesystem size can be checked with df command when mounted, and partition size with blockdev. Just like HDDs or SSDs on PC, Android's eMMC storage is divided into partitions (can be 50+). Some of them have filesystem e.g. the larger ones userdata and system. In simple cases a filesystem occupies a complete physical partition, but it's not always the case, LVM makes it possible to have single filesystem on multiple partitions. Or the opposite what happened in your case as explained here: Sometimes the zip file of: a custom ROM does not have the correct size for the system partition and if the ROM flashes a raw system image, that image will not take up the full block device. Running resize2fs can fix the size Similarly: Sometimes flashing a factory image may flash userdata with an image with a file system that does not take up the full size of the block device So TWRP can expand the filesystem to reclaim wasted space. That's what happened in your case to the /system partition. The actual size of partition was 2.5 GB, but flashed image was of 1.5 GB. Coming to your query: I realized that the system partition is too big (~1.5GB). The current ROM uses only about 40% of the partition so I want to shrink it to make space for cache and data. You want to resize partition, not filesystem. So resize2fs (which TWRP uses at back end) isn't the right choice. As your partition table suggests, you need to delete and recreate partitions 9 to 12. IT'S DANGEROUS AND NOT RECOMMENDED, you may permanently brick your device. All data on these partitions will be lost, so do backup. Also, fdisk isn't proper tool for GPT, it's for MBR partition scheme. Use parted or gdisk instead, but with great care.
So now you can just resize the system partition in case it's size is smaller than the image (not likely in my opinion)
animegamer4422 said:
I'd love to test it , but currently I'm not at my home and my A7 is at home (since It's not my daily driver) but I'll test it as soon as I can get back home
Until then
Keep figuring out things
Also I think you can use the TWRP terminal to Change the size of system partition using the resize2fs command i guess
I found this when I looked into it
First to clarify, Resize Partition is different than Resize File System, TWRP provides latter option. It resizes the ext2/3/4 filesystem to the size of partition it's created on. Filesystem size can be checked with df command when mounted, and partition size with blockdev. Just like HDDs or SSDs on PC, Android's eMMC storage is divided into partitions (can be 50+). Some of them have filesystem e.g. the larger ones userdata and system. In simple cases a filesystem occupies a complete physical partition, but it's not always the case, LVM makes it possible to have single filesystem on multiple partitions. Or the opposite what happened in your case as explained here: Sometimes the zip file of: a custom ROM does not have the correct size for the system partition and if the ROM flashes a raw system image, that image will not take up the full block device. Running resize2fs can fix the size Similarly: Sometimes flashing a factory image may flash userdata with an image with a file system that does not take up the full size of the block device So TWRP can expand the filesystem to reclaim wasted space. That's what happened in your case to the /system partition. The actual size of partition was 2.5 GB, but flashed image was of 1.5 GB. Coming to your query: I realized that the system partition is too big (~1.5GB). The current ROM uses only about 40% of the partition so I want to shrink it to make space for cache and data. You want to resize partition, not filesystem. So resize2fs (which TWRP uses at back end) isn't the right choice. As your partition table suggests, you need to delete and recreate partitions 9 to 12. IT'S DANGEROUS AND NOT RECOMMENDED, you may permanently brick your device. All data on these partitions will be lost, so do backup. Also, fdisk isn't proper tool for GPT, it's for MBR partition scheme. Use parted or gdisk instead, but with great care.
So now you can just resize the system partition in case it's size is smaller than the image (not likely in my opinion)
Click to expand...
Click to collapse
The /system partition is 3.9G big.
This is everything:
https://imgur.com/MOKz0uR
Arm1nas said:
The /system partition is 3.9G big.
This is everything:
https://imgur.com/MOKz0uR
Click to expand...
Click to collapse
Sorry i was sick from past 2 days so couldn't reply earlier
Anyways could you like drop to a shell when you boot up postmarketOS
If yes then check the dmesg
I also think you'll have to flash a special kernel which could also be obtained from the pmbootstrap tool
Also it'd be great if you could record a video of the phone booting up into postmarketOS as that'd help us understand until how far it can reach and where it gets stuck
Thanks alot and Take care
animegamer4422 said:
Sorry i was sick from past 2 days so couldn't reply earlier
Anyways could you like drop to a shell when you boot up postmarketOS
If yes then check the dmesg
I also think you'll have to flash a special kernel which could also be obtained from the pmbootstrap tool
Also it'd be great if you could record a video of the phone booting up into postmarketOS as that'd help us understand until how far it can reach and where it gets stuck
Thanks alot and Take care
Click to expand...
Click to collapse
Hello, did you make any progress with it? I will try installing pmOS again and recording everything.
This is my installation procedure:
On a Ubuntu 20.04 VM I run:
$ pmbootstrap init
I select my device, DE, go through the setup.
Then I type:
$ pmbootstrap install --android-recovery-zip
$ pmbootstrap export
Then on the phone I unmount everything:
https://imgur.com/PlQZ1oB
Go to ADB sideload:
https://imgur.com/xf1FBzQ
https://imgur.com/H9AbkXY
I connect the phone to my computer and use this command to install pmOS:
$ adb sideload pmos.zip
I recorded the installation procedure:
As you can see it boots up the first time, the file system only has 2.6GB free, when it reboots again, it just boots into busybox terminal. When trying to boot up it gives me these errors:
https://imgur.com/qEtwRlx
I logged in and typed:
$ df -H
This is the output:
https://imgur.com/7n61Vm3
If I try to start the desktop environment with $ startx command I get these errors:
https://imgur.com/8xOA1kc
dmesg output:
https://imgur.com/eizBP3m
https://imgur.com/nP8aAaB
This is the phone's partition layout:
https://imgur.com/9xNmaAV
https://i.imgur.com/M0m3GjW.png
D
Arm1nas said:
This is my installation procedure:
On a Ubuntu 20.04 VM I run:
$ pmbootstrap init
I select my device, DE, go through the setup.
Then I type:
$ pmbootstrap install --android-recovery-zip
$ pmbootstrap export
Then on the phone I unmount everything:
https://imgur.com/PlQZ1oB
Go to ADB sideload:
https://imgur.com/xf1FBzQ
https://imgur.com/H9AbkXY
I connect the phone to my computer and use this command to install pmOS:
$ adb sideload pmos.zip
I recorded the installation procedure:
As you can see it boots up the first time, the file system only has 2.6GB free, when it reboots again, it just boots into busybox terminal. When trying to boot up it gives me these errors:
https://imgur.com/qEtwRlx
Click to expand...
Click to collapse
Sorry for the late reply
Anyways i just got home and have the smartphone I'm my hands
So i can too test it out
Also I think we should try switching to Wayland as X seems to be crashing
By using Wayland if it works we'll know that it's not a Xorg issue but if Wayland too fails we'll know that it's a big in the Kernel and the way it handles hardware
Also could you create a Telegram group for us to chat instantly I think that way we can help each other better and then we'll just create a general guide on fixing things ok XDA
(I cannot post links since I didn't started the thread)[/url]
Arm1nas said:
This is my installation procedure:
On a Ubuntu 20.04 VM I run:
$ pmbootstrap init
I select my device, DE, go through the setup.
Then I type:
$ pmbootstrap install --android-recovery-zip
$ pmbootstrap export
Then on the phone I unmount everything:
https://imgur.com/PlQZ1oB
Go to ADB sideload:
https://imgur.com/xf1FBzQ
https://imgur.com/H9AbkXY
I connect the phone to my computer and use this command to install pmOS:
$ adb sideload pmos.zip
I recorded the installation procedure:
As you can see it boots up the first time, the file system only has 2.6GB free, when it reboots again, it just boots into busybox terminal. When trying to boot up it gives me these errors:
https://imgur.com/qEtwRlx
I logged in and typed:
$ df -H
This is the output:
https://imgur.com/7n61Vm3
If I try to start the desktop environment with $ startx command I get these errors:
https://imgur.com/8xOA1kc
dmesg output:
https://imgur.com/eizBP3m
https://imgur.com/nP8aAaB
This is the phone's partition layout:
https://imgur.com/9xNmaAV
https://i.imgur.com/M0m3GjW.png
Click to expand...
Click to collapse
Sorry for the late reply
Anyways ...post links since I didn't started the thread)
Arm1nas said:
This is my installation procedure:
On a Ubuntu 20.04 VM I run:
$ pmbootstrap init
I select my device, DE, go through the setup.
Then I type:
$ pmbootstrap install --android-recovery-zip
$ pmbootstrap export
Then on the phone I unmount everything:
https://imgur.com/PlQZ1oB
Go to ADB sideload:
https://imgur.com/xf1FBzQ
https://imgur.com/H9AbkXY
I connect the phone to my computer and use this command to install pmOS:
$ adb sideload pmos.zip
I recorded the installation procedure:
As you can see it boots up the first time, the file system only has 2.6GB free, when it reboots again, it just boots into busybox terminal. When trying to boot up it gives me these errors:
https://imgur.com/qEtwRlx
I logged in and typed:
$ df -H
This is the output:
https://imgur.com/7n61Vm3
If I try to start the desktop environment with $ startx command I get these errors:
https://imgur.com/8xOA1kc
dmesg output:
https://imgur.com/eizBP3m
https://imgur.com/nP8aAaB
This is the phone's partition layout:
https://imgur.com/9xNmaAV
https://i.imgur.com/M0m3GjW.png
Click to expand...
Click to collapse
I installed plasma desktop and it seems to be working great though there's no on screen keyboard so i had to use a USB OTG to connect a external keyboard and unlock the device and use it And also the performance is not very great it lags alot probably due to the lack of GPU acceleration
animegamer4422 said:
I installed plasma desktop and it seems to be working great though there's no on screen keyboard so i had to use a USB OTG to connect a external keyboard and unlock the device and use it And also the performance is not very great it lags alot probably due to the lack of GPU acceleration
Click to expand...
Click to collapse
What method did you use to flash pmOS? And what recovery do you have? Mind sharing the built pmOS files, so I can flash it myself?
Arm1nas said:
What method did you use to flash pmOS? And what recovery do you have? Mind sharing the built pmOS files, so I can flash it myself?
Click to expand...
Click to collapse
I created a recovery zip using Pmbootstrap and also I set the free space parameter (after running pmbootstrap init) to 2000mb (2gb)
And then i copied that zip file from the temp directory to a Pendrive and connected the pendrive to the phone in recovery mode (PBRP Recovery) and then flashed it
I'll upload the files in a bit
Also I tried using Phosh but it just gets to the Login TTY and then doesn't boots up and i think that's because the device lacks GPU acceleration
Also here's a Telegram group link which I'll delete once you join the group
~REMOVED~
M0Rf30 said:
Hi guys,
Here, for those who are interested, I'm maintaining the packages to use postmarketOS on bare-metal hardware.
I only tested the A750FN variant.
Check it out!
Feedbacks are welcome!
Many thanks:
@VDavid003 for kernel sources
Click to expand...
Click to collapse
hello, are this thread still active?
Hey everyone
I am working on a dual boot Ubuntu Touch, Droidian (mobian-hybris) setup without breaking either of the systems. I have figured everything out on how everything should work and modifications that need to be done to the recovery image but there is one question that i do not have an answer for but here is some information but how things work.
So right now Ubuntu Touch uses a customized version of LineageOS recovery to do OTA updates. and is when installed it replaces androids rootfs. Then we have Droidian which uses a rootfs.img file as its rootfs which is mounted at boot as a loop device. (file is placed in /data)
They use different kernels because they have different ramdisks (obviously). My plan is to write a desktop file in both OSes to create a file to let recovery know to flash the right kernel (kernels will be placed under /data aswell no space limitations). I have the recovery and desktop file code mostly ready the only remaining thing is the command to flash a kernel.img/boot.img file to the device (Redmi Note 9S)
I know that LineageOS does not have a terminal all of the flashing tasks will be done by a script which checks which kernel should be flashed.
Is there some documentation on this? Because TWRP can do the same and TWRP is just a GUI on top of the android shell with some added functionality for backups and such.
Any response is appreciated.
FakeShell said:
Hey everyone
I am working on a dual boot Ubuntu Touch, Droidian (mobian-hybris) setup without breaking either of the systems. I have figured everything out on how everything should work and modifications that need to be done to the recovery image but there is one question that i do not have an answer for but here is some information but how things work.
So right now Ubuntu Touch uses a customized version of LineageOS recovery to do OTA updates. and is when installed it replaces androids rootfs. Then we have Droidian which uses a rootfs.img file as its rootfs which is mounted at boot as a loop device. (file is placed in /data)
They use different kernels because they have different ramdisks (obviously). My plan is to write a desktop file in both OSes to create a file to let recovery know to flash the right kernel (kernels will be placed under /data aswell no space limitations). I have the recovery and desktop file code mostly ready the only remaining thing is the command to flash a kernel.img/boot.img file to the device (Redmi Note 9S)
I know that LineageOS does not have a terminal all of the flashing tasks will be done by a script which checks which kernel should be flashed.
Is there some documentation on this? Because TWRP can do the same and TWRP is just a GUI on top of the android shell with some added functionality for backups and such.
Any response is appreciated.
Click to expand...
Click to collapse
Answering my question as the answer was just too dumb but for some reason i could not figure it out.
dd can be used like a regular linux machine
dd if=/data/boot.img of=/dev/block/platform/soc/by-name/boot
Closing down
I kinda had the same issue here: https://forum.xda-developers.com/t/...wrp-openrecoveryscript.4301279/#post-85681605
I remember that I read somewhere / was told actually not to use /dev/block/platform/soc/by-name/boot (which is a symlink) but the actual device path the symlink resolves to with dd.
I'm not sure what the reasoning was though. I'd like to mention this here, maybe someone knows why.