Related
Hi,
i installed Shadow Hawk, but Wifi doesn´t work. It´s because of the Hyperion Kernel. I just don´t know how to "replace the broadcom module inside /system/etc/lib/modules". Because i used HTCDev(il) to unlock, i flash boot.img with fastboot. But how do i replace the broadcom module?
Please help!
Given your handset is S-OFF, either,
- Hard way :
Use android SDK adb to mount system RW and push module file :
Code:
adb shell mount -o remount,rw -t yaffs2 /dev/block/mmcblk0p25 /system
adb pull c:\bcm4329.ko /system/lib/modules/bcm4329.ko
- Easy way :
Just use ES file explorer, enable root R/W mode and copy/paste bcm4329.ko into /system/lib/modules
And then reboot.
dmfr said:
Code:
adb shell mount -o remount,rw -t yaffs2 /dev/block/mmcblk0p25 /system
adb pull c:\bcm4329.ko /system/lib/modules/bcm4329.ko
And then reboot.
Click to expand...
Click to collapse
If you use adb, those are not the commands. Should be:
adb remount
adb push :\bcm4329.ko /system/lib/modules/bcm4329.ko
In your first line you were trying to mount a yaffs2 filesystem, when it's probably a ext4 one. The "remount" option will work regardless of the fs.
Ths second line is fairly obvious, you want to push the file to the rom, not pull it from there.
Also, if you S-ON and flashed the rom, the broadcom module was flashed, it's just boot.img that gets left out. This means that when you manualy flash boot.img with fastboot, you don't need to update anything else.
So: Check in system settings if you actually flashed the kernel. It must say "Hyperion V2.XXX", or whatever version was included. If it is, wifi must work, if not, you messed something up on the fastboot flash procedure.
Cheers
will try later, thank you.
ICS Quattro Rom worked including Wifi..
update:
working now.
"Please follow these steps in the same order (I'm shouting) :
1. Boot into recovery
2. Format System (not wipe option but format option !!!)
3. Format Data
4. Format Cache then Format Boot
5. Wipe Data/Factory reset (1st option in wipe/format menu)
6. Wipe Dalvik Cache
Next if you have some wiping utility like Full Wipe 1.5 Ext4 for Saga.zip...run that by selecting install zip from sd card and installing the zip...
7. Now install zip from sd card and flash the rom
8. If any kernel flash it as well
9. Now reboot (Note don't flash any tweaks like transparent notification except gapps if required)
10. Now setup your phone
11. Reboot into recovery
12. Now go into advanced fix permissions and then any tweaks you want (Note whether mentioned or not always wipe Dalvik Cache before installing tweak zip)
13. Voila everything would work perfect 100%.... "
did follow these instructions.
flashed boot.img
having a fast and stable rom now hopefully. ICS wasnt stable enough. especially browser.
Hey guys,
I just can't figure this one on my own. My phone is bricked, so I'm trying to use ADB in Recovery mode to fix it. The problem is, that 'su' always returns 'permission denied', so I can't mount system rw and that's where I'm stuck.
Phone is fully rooted - that's how I was able to brick it in the first place.
'/system/xbin/su' is also present (checked via Aroma).
Is there any way to "fix" this?
in the recovery go to mount and storage then mount /system.It will be mounted as RW.
I have the e3 stock recovery, so there are only these options:
reboot system now
apply update from sdcard
wipe data/factory reset
wipe cache partition
use aroma file manager it have terminal.You can use it in recovery.
or try adb remount
Yes, I know about the aroma terminal and I also tried some commands in it, but without a positive result. But just to be sure, what command(s) did you have in mind?
And 'adb remount' returns:
remount failed: Operation not permitted
if you have e3 recovery that means you havent rooted your phone which means su wont work first root your phone
also it would be great if you could explain a little more as to what you want to accomplish
Oh.. That doesn't sound very good..
I need to modify some files in the system/framework folder.
Anyway, it should be rooted, because I already replaced a system file.
I just found out on the web that in the system settings on CM10 -> Developer settings -> you can set root access also for ADB.
Maybe it helps?
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.
Starting with Android L/Lollipop/5.0, full device encryption will be enabled by default, and for good reason. However, we slightly more security-conscious/paranoid SGS3 users have had problems for a while with using custom ROMs and keeping our encryption, as the main custom recovery with support for encryption --- TWRP --- has some incorrect build flags and other problems that aren't considered a priority. However, thanks to the very same bug report and discussion on the issue on TWRP's pages, someone found a solution which I can confirm works for me as well: https://github.com/TeamWin/Team-Win-Recovery-Project/issues/247#issuecomment-52651670
One option would be to check whether CWM Recovery supports your device. Then you'll have access to MiniVold in recovery mode and you can mount encrypted partitions through adb. I prefer the TWR method of just typing in my password, but as long as that does not work on my Galaxy S3, this does:
adb shell
setprop ro.crypto.state encrypted
vdc cryptfs checkpw 'your passphrase here'
mount /dev/block/dm-0 /data
and when you're done backing up/installing a zip
umount /data
Click to expand...
Click to collapse
For Windows users, here's a batch file you can use to automate this process:
Code:
adb shell setprop ro.crypto.state encrypted
adb shell vdc cryptfs checkpw "%~1"
adb shell mount /dev/block/dm-0 /data
Save it under whateveryouwant.bat and then give it the password as a parameter (if the password contains spaces, enclose it in quotes).
Caveat: I've found some operations will unmount /data, which for some reason cannot then be re-mounted by any combination of these commands. Workaround is to just reboot Philz Touch Recovery / CWM Advanced Recovery, re-mount, and continue.
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