How To Guide How to add additional files to an TWRP image - ASUS ZenFone 8

How to add additonal files to an TWRP image
The recovery image TWRP is very useful for the maintenance of the Android OS.
It's the Swiss Army knife for maintaining phones running the Android OS but sometimes you might miss some files in the TWRP recovery.
To add additional files to an TWRP image the instructions from the HowTo How to change files in the boot image can be used.
To make sure that the new files are also added to an TWRP installed in the boot partition additional steps are necessary.
To unpack and repack the TWRP image the Magisk binary magiskboot is necessary. This binary is part of TWRP so creating the new image should be done while the phone is booted from the TWRP image.
So to add additional files to an TWRP image do:
Bash:
# boot into the TWRP image
#
adb reboot bootloader
sudo fastboot boot /data/backup/ASUS_ZENFONE8/twrp/twrp-3.7.0_12-0-I006D.img
Wait until booting the TWRP image is done and open an adb shell
Bash:
adb shell
Create some directories for the work on the phone:
Bash:
mkdir -p /data/develop/workdir/twrp/ramdisk
Copy the TWRP image file from your PC to the working directory on the phone
Bash:
adb push twrp-3.7.0_12-0-I006D.img /data/develop/workdir/twrp
Unpack the image file:
Bash:
cd /data/develop/workdir/twrp
magiskboot unpack -h twrp-3.7.0_12-0-I006D.img
e.g.
Code:
ASUS_I006D:/data/develop/workdir/twrp # magiskboot unpack -h twrp-3.7.0_12-0-I006D.img
Parsing boot image: [twrp-3.7.0_12-0-I006D.img]
HEADER_VER [3]
KERNEL_SZ [18627321]
RAMDISK_SZ [34811448]
OS_VERSION [99.87.36]
OS_PATCH_LEVEL [2099-12]
PAGESIZE [4096]
CMDLINE [twrpfastboot=1]
KERNEL_FMT [gzip]
RAMDISK_FMT [gzip]
VBMETA
ASUS_I006D:/data/develop/workdir/twrp #
ASUS_I006D:/data/develop/workdir/twrp # ls -ltr
total 324223
-rw-rw---- 1 u0_a119 media_rw 100663296 2022-10-12 13:38 twrp-3.7.0_12-0-I006D.img
-rw-r--r-- 1 root root 100663296 2022-10-28 15:55 new-boot.img
-rw-rw-rw- 1 root root 66 2022-10-28 16:14 header
-rw-r--r-- 1 root root 41943552 2022-10-28 16:14 kernel
-rw-r--r-- 1 root root 88384000 2022-10-28 16:14 ramdisk.cpio
drwxrwxrwx 2 root root 3452 2022-10-28 16:15 ramdisk
ASUS_I006D:/data/develop/workdir/twrp #
Unpack the ramdisk from the TWRP image:
Bash:
cd /data/develop/workdir/twrp/ramdisk
cpio -idm <../ramdisk.cpio
The directory /data/develop/workdir/twrp/ramdisk now contains the contents of the ramdisk used for TWRP.
Now add the new files for the image to the directory /data/develop/workdir/twrp/ramdisk:
In this example we will add the binaries zsh, sqlite3, and vi.
Bash:
cd /data/develop/workdir/twrp/ramdisk
cp ../../newfiles/sqlite3 ./system/bin/
cp ../../newfiles/zsh ./system/bin/
cp ../../newfiles/vi ./system/bin/
Note:
In case you want to add new binaries :
To check if the binaries will work in TWRP execute the binaries while the phone is booted from the original TWRP image. If the binaries need additional libraries not included in TWRP just also add them to the TWRP image into the directory ./system/lib64 of the image.
The next step is necessary to make sure that TWRP will copy the new files also to a TWRP installation in a boot partition:
For each new file add an entry to the files
./ramdisk-files.sha256sum
./ramdisk-files.txt
in the directory with the contents from the ramdisk.
The file ramdisk-files.txt contains the name and path of the files used in the ramdisk for the boot partition and the file ramdisk-files.sha256sum contains the checksum for each of the files for the ramdisk.
Note:
If you change an existing file that is mentioned in the file ./ramdisk-files.sha256sum you must also correct the entry in that file.
So do for each new file:
echo <file_with_path_not_starting_with_a_dot_or_slash> >>ramdisk-files.txt ; done
sh256sum <file_with_path_startinge with_a_slash> >>ramdisk-files.sha256sum
e.g:
Code:
ASUS_I006D:/data/develop/workdir/twrp/ramdisk # for i in system/bin/sqlite3 system/bin/vi system/bin/zsh ; do sha256sum ./$i >>ramdisk-files.sha256sum ; echo "$i" >>ramdisk-files.txt ; done
ASUS_I006D:/data/develop/workdir/twrp/ramdisk #
Check the result.
Code:
ASUS_I006D:/data/develop/workdir/twrp/ramdisk # tail -4 ramdisk-files.sha256sum
8a8ff76cbda445f08ba3552598085089883f9d594cd7716e90f3411a8b82f8a0 ./twres/fonts/DroidSansMono.ttf
09fcec146d9ecba0f2a0b7362b52d2f87607a3c5760c94ba5fcd900e423e16f8 ./system/bin/sqlite3
3a221d10ffc275cadaf79fb1a00c39c9083ce672ea111205301e277091a04b51 ./system/bin/vi
354e415da42503ed4211907adf93ed8bfb14ce2e2d8418fcd7a3227873b4b53f ./system/bin/zsh
ASUS_I006D:/data/develop/workdir/twrp/ramdisk #
ASUS_I006D:/data/develop/workdir/twrp/ramdisk # tail -4 ramdisk-files.txt
twres/fonts/DroidSansMono.ttf
system/bin/sqlite3
system/bin/vi
system/bin/zsh
ASUS_I006D:/data/develop/workdir/twrp/ramdisk #
Correct the entry for the file ramdisk-files.txt in the file ramdisk-files.sha256sum :
Bash:
cd /data/develop/workdir/twrp/ramdisk
cp ./ramdisk-files.sha256sum ./ramdisk-files.sha256sum.org
NEW_ENTRY="$( sha256sum ./ramdisk-files.txt )" && sed -i -e "s#.*\./ramdisk-files.txt#${NEW_ENTRY}#g" ./ramdisk-files.sha256sum
Check the entries in the file ramdisk-files.sha256sum
Bash:
sha256sum --status -c ./ramdisk-files.sha256sum ; echo $?
If the output of that command is not 0 use
Bash:
sha256sum -c ./ramdisk-files.sha256sum | grep -v OK
to get the entry with the invalid checksum. Fix the entry and check again.
Now repack the ramdisk:
Bash:
cd /data/develop/workdir/twrp/ramdisk
find . | cpio -o >../ramdisk.cpio
And recreate the image file:
Bash:
cd /data/develop/workdir/twrp
magiskboot repack twrp-3.7.0_12-0-I006D.img
e.g
Code:
ASUS_I006D:/data/develop/workdir/twrp # magiskboot repack twrp-3.7.0_12-0-I006D.img
Parsing boot image: [twrp-3.7.0_12-0-I006D.img]
HEADER_VER [3]
KERNEL_SZ [18627321]
RAMDISK_SZ [34811448]
OS_VERSION [99.87.36]
OS_PATCH_LEVEL [2099-12]
PAGESIZE [4096]
CMDLINE [twrpfastboot=1]
KERNEL_FMT [gzip]
RAMDISK_FMT [gzip]
VBMETA
Repack to boot image: [new-boot.img]
HEADER_VER [3]
KERNEL_SZ [18618540]
RAMDISK_SZ [37358888]
OS_VERSION [99.87.36]
OS_PATCH_LEVEL [2099-12]
PAGESIZE [4096]
CMDLINE [twrpfastboot=1]
ASUS_I006D:/data/develop/workdir/twrp #
The file new-boot.img contains the TWRP image with the additional files.:
ASUS_I006D:/data/develop/workdir/twrp # ls -ltr new-boot.img
-rw-r--r-- 1 root root 100663296 2022-10-28 16:28 new-boot.img
ASUS_I006D:/data/develop/workdir/twrp #
To test the image, rename the file, copy the file to an PC and boot the phone from the image:
Bash:
mv new-boot.img twrp-3.7.0_12-0-I006D-enhanced.img
Execute on the PC:
Bash:
adb pull /data/develop/workdir/twrp/twrp-3.7.0_12-0-I006D-enhanced.img
adb reboot bootloader
sudo fastboot boot twrp-3.7.0_12-0-I006D-enhanced.img
Connect via adb to the phone booted from the new TWRP image and check the result:
Code:
ASUS_I006D:/ # ls -l /system/bin/zsh /system/bin/sqlite3 /system/bin/vi
-rwxr-xr-x 1 root root 1714720 2022-10-28 16:19 /system/bin/sqlite3
-rwxr-xr-x 1 root root 1815152 2022-10-28 16:19 /system/bin/vi
-rwxr-xr-x 1 root root 2004808 2022-10-28 16:19 /system/bin/zsh
ASUS_I006D:/ #
ASUS_I006D:/ # /system/bin/sqlite3 --version
3.39.3 2022-09-05 11:02:23 4635f4a69c8c2a8df242b384a992aea71224e39a2ccab42d8c0b0602f1e826e8
ASUS_I006D:/ #
ASUS_I006D:/ # /system/bin/vi --version | head -1
VIM - Vi IMproved 8.1 (2018 May 18)
ASUS_I006D:/ #
ASUS_I006D:/ # /system/bin/zsh --version
zsh 5.9 (aarch64-unknown-linux-android)
ASUS_I006D:/ #
Advanced Usage
To be able to distinguish the new image from the original one you can change or add values in the file ./default.prop in the ramdisk for the image, e.g.:
Bash:
# before creating the new ramdisk
cd /data/develop/workdir/twrp/ramdisk
echo "ro.product.type=enhanced" >>default.prop
Then when booted from the image you can check the new property, e.g.:
Code:
ASUS_I006D:/ # getprop ro.product.type
enhanced
ASUS_I006D:/ #
Notes:
The file default.prop is not listed in the checksum file ramdisk-files.sha256sum for the image.
Adding new files to ramdisk-files.sha256sum is not mandatory but recommended
To add files to the image that should not be copied to an TWRP installation in a boot partition just add them to the ramdisk but not to the file ramdisk-files.txt.
see also How to install TWRP via script
Update 28.11.2022 /bs
see als How to compile TWRP for the ASUS Zenfone 8

Related

[MOD][P31XX] How to patch stock kernel to install CWM

After installing stock versions of 4.0.4, 4.1.1, or 4.1.2, the kernel will mount the recovery partition as read only so that ClockWorkMod (or any other recovery) will not install properly. Here are the commands to fix the kernel so that it mounts the recovery partition as writable and turns off secure mode:
The following commands below assume that you have already downloaded your desired firmware from sammobile.com and have extracted the boot.img (kernel) file from it using the tar utility. This tutorial is for Linux only and tested on Ubuntu 12.04.
Code:
unmkbootimg boot.img
mkdir ramdisk
cd ramdisk
gunzip -c ../initramfs.cpio.gz | cpio -i
patch -p1 < ../ro.secure.diff
find . | cpio -o -H newc | gzip > ../initramfs-new.cpio.gz
cd ..
mkbootimg --kernel kernel.gz --ramdisk initramfs-new.cpio.gz --base 0x80000000 --cmdline 'console=ttyO2,115200n8 mem=1024M androidboot.console=ttyO2 vram=20M omapfb.vram=0:16M androidboot.carrier=wifi' -o new_boot.img
Contents of patch (ro.secure.diff):
Code:
--- ramdisk/default.prop.org 2013-02-18 03:40:22.442572189 +0100
+++ ramdisk/default.prop 2013-02-18 03:40:56.158572156 +0100
@@ -1,7 +1,7 @@
#
# ADDITIONAL_DEFAULT_PROPERTIES
#
-ro.secure=1
+ro.secure=0
ro.allow.mock.location=0
ro.debuggable=0
persist.sys.usb.config=mtp
I have attached also below an example of the flash-able zip file used for installing the new boot.img through ClockworkMod. Just replace the boot.img inside the kernel.zip file with the new boot.img that you just created from the directions above and sign the zip (signing is optional).

How To Guide How to change files in the boot image using Magisk

How to change files in the boot image using Magisk
Sometime it's necessary to change a file in the boot image used for booting an Android phone (for example to change the default properties that are used before Magisk is loaded)
To change or add files to the boot image for an Android phone the Magisk binary magiskboot can be used
magiskboot is
A tool to unpack / repack boot images, parse / patch / extract cpio, patch dtb, hex patch binaries, and compress / decompress files with multiple algorithms.
Click to expand...
Click to collapse
and can handle the boot images for all phones supported by Magisk.
Warning
Be aware that changes to the boot image only survive until the installation of the next OS update. So it's strongly recommended to use Magisk to change files from the OS if possible.
Anyway -- to change a file in the boot image open a shell as user root on the phone and do:
Notes:
The following instructions were done on Zenfone 8 running OmniROM 12 but should also work for other ROMs.
At the end of this post are the commands to unpack the boot partition and to recreate the boot partition listed for cut & paste.
Code:
#
# first create the directory tree for the work
#
# Note:
#
# This directory tree must be on a Unix filesystem like that mounted to /data;
# a filesystem like that mounted to /sdcard does not work
#
ASUS_I006D:/data/adb # cd /data/adb
ASUS_I006D:/data/adb # mkdir workdir
ASUS_I006D:/data/adb # mkdir workdir/backup
ASUS_I006D:/data/adb # mkdir workdir/ramdisk
ASUS_I006D:/data/adb # mkdir workdir/boot_files
ASUS_I006D:/data/adb #
Next get the current boot slot:
Code:
ASUS_I006D:/data/adb/workdir # getprop ro.boot.slot_suffix
_b
and create an image of the current boot partition:
Code:
#
ASUS_I006D:/ # cd /data/adb/workdir
ASUS_I006D:/data/adb/workdir #
ASUS_I006D:/data/adb/workdir # dd if=/dev/block/by-name/boot_b of=./boot_b.img
196608+0 records in
196608+0 records out
100663296 bytes (96 M) copied, 0.374815 s, 256 M/s
ASUS_I006D:/data/adb/workdir #
Create a backup of the original boot image file:
Code:
ASUS_I006D:/data/adb/workdir # cp boot_b.img backup/
ASUS_I006D:/data/adb/workdir #
Note:
You will need the boot image file just created to restore the boot partition in case the phone will not boot anymore with your changed boot partition. Therefor you should also copy the boot image file to your PC.
Next unpack the boot image using magiskboot into an empty directory:
Code:
ASUS_I006D:/data/adb/workdir # cd boot_files/
ASUS_I006D:/data/adb/workdir/boot_files # ls
ASUS_I006D:/data/adb/workdir/boot_files #
ASUS_I006D:/data/adb/workdir/boot_files # /data/adb/magisk/magiskboot unpack ../boot_b.img
Parsing boot image: [../boot_b.img]
HEADER_VER [3]
KERNEL_SZ [42025472]
RAMDISK_SZ [15093897]
OS_VERSION [12.0.0]
OS_PATCH_LEVEL [2022-05]
PAGESIZE [4096]
CMDLINE []
KERNEL_FMT [raw]
RAMDISK_FMT [gzip]
VBMETA
ASUS_I006D:/data/adb/workdir/boot_files #
magiskboot will split the boot.img file into the various parts -- for most phones with Android 12 this should be the kernel and the ramdisk:
Code:
ASUS_I006D:/data/adb/workdir/boot_files # ls -l
total 71264
-rw-r--r-- 1 root root 42025472 2022-09-18 18:22 kernel
-rw-r--r-- 1 root root 30864336 2022-09-18 18:22 ramdisk.cpio
ASUS_I006D:/data/adb/workdir/boot_files #
The files for the ramdisk used while booting the phone are in an cpio archive so to change them we must unpack the cpio archive with the ramdisk contents:
Code:
#
ASUS_I006D:/ # cd /data/adb/workdir/ramdisk/
ASUS_I006D:/data/adb/workdir/ramdisk #
130|ASUS_I006D:/data/adb/workdir/ramdisk # cpio -idm <../boot_files/ramdisk.cpio
ASUS_I006D:/data/adb/workdir/ramdisk # ls -ltr
total 1868
-rw-r--r-- 1 root root 20700 1970-01-01 01:00 vendor_property_contexts
-rw-r--r-- 1 root root 89884 1970-01-01 01:00 vendor_file_contexts
drwxr-xr-x 2 root root 3452 1970-01-01 01:00 vendor
drwxr-xr-x 2 root root 3452 1970-01-01 01:00 tmp
-rw-r--r-- 1 root root 5783 1970-01-01 01:00 system_ext_property_contexts
-rw-r--r-- 1 root root 3347 1970-01-01 01:00 system_ext_file_contexts
drwxr-xr-x 2 root root 3452 1970-01-01 01:00 system_ext
drwxr-xr-x 2 root root 3452 1970-01-01 01:00 sys
drwxr-x--x 2 root root 3452 1970-01-01 01:00 storage
-rw-r--r-- 1 root root 1027673 1970-01-01 01:00 sepolicy
drwxr-xr-x 2 root root 3452 1970-01-01 01:00 second_stage_resources
drwxr-xr-x 2 root root 3452 1970-01-01 01:00 sdcard
-rw-r--r-- 1 root root 31390 1970-01-01 01:00 prop.default
-rw-r--r-- 1 root root 1721 1970-01-01 01:00 product_property_contexts
-rw-r--r-- 1 root root 306 1970-01-01 01:00 product_file_contexts
drwxr-xr-x 2 root root 3452 1970-01-01 01:00 product
drwxr-xr-x 2 root root 3452 1970-01-01 01:00 proc
drwxr-xr-x 2 root root 3452 1970-01-01 01:00 postinstall
-rw-r--r-- 1 root root 76958 1970-01-01 01:00 plat_property_contexts
-rw-r--r-- 1 root root 40490 1970-01-01 01:00 plat_file_contexts
drwxr-xr-x 2 root root 3452 1970-01-01 01:00 oem
-rw-r--r-- 1 root root 0 1970-01-01 01:00 odm_property_contexts
-rw-r--r-- 1 root root 0 1970-01-01 01:00 odm_file_contexts
drwxr-xr-x 2 root root 3452 1970-01-01 01:00 mnt
drwxr-xr-x 2 root root 3452 1970-01-01 01:00 metadata
drwxr-xr-x 2 root root 3452 1970-01-01 01:00 linkerconfig
-rwxr-x--- 1 root root 2025 1970-01-01 01:00 init.recovery.qcom.rc
-rwxr-x--- 1 root root 491528 1970-01-01 01:00 init
lrwxrwxrwx 1 root root 11 1970-01-01 01:00 etc -> /system/etc
drwxr-xr-x 2 root root 3452 1970-01-01 01:00 dev
lrwxrwxrwx 1 root root 12 1970-01-01 01:00 default.prop -> prop.default
drwxr-xr-x 2 root root 3452 1970-01-01 01:00 debug_ramdisk
drwxr-xr-x 2 root root 3452 1970-01-01 01:00 data_mirror
drwxr-x--x 2 root root 3452 1970-01-01 01:00 data
lrwxrwxrwx 1 root root 17 1970-01-01 01:00 d -> /sys/kernel/debug
dr-xr-xr-x 2 root root 3452 1970-01-01 01:00 config
lrwxrwxrwx 1 root root 50 1970-01-01 01:00 bugreports -> /data/user_de/0/com.android.shell/files/bugreports
lrwxrwxrwx 1 root root 11 1970-01-01 01:00 bin -> /system/bin
drwxr-xr-x 2 root root 3452 1970-01-01 01:00 batinfo
drwxr-xr-x 2 root root 3452 1970-01-01 01:00 asdf
drwxr-xr-x 2 root root 3452 1970-01-01 01:00 apex
drwxr-xr-x 2 root root 3452 1970-01-01 01:00 acct
drwxr-xr-x 2 root root 3452 1970-01-01 01:00 APD
drwxr-xr-x 2 root root 3452 1970-01-01 01:00 ADF
drwxr-xr-x 4 root root 3452 2022-09-18 18:28 first_stage_ramdisk
drwxr-x--- 3 root root 3452 2022-09-18 18:28 overlay.d
drwxr-xr-x 2 root root 3452 2022-09-18 18:28 odm_dlkm
drwxr-xr-x 2 root root 3452 2022-09-18 18:28 odm
drwxr-xr-x 3 root root 3452 2022-09-18 18:28 res
drwxr-xr-x 5 root root 3452 2022-09-18 18:28 system
drwxr-xr-x 2 root root 3452 2022-09-18 18:28 vendor_dlkm
ASUS_I006D:/data/adb/workdir/ramdisk #
Now you can change the files from the ramdisk; add new files, or do anything necessary.
Be aware that most of the directories in the ramdisk are mount points to mount the other partitions. Therefor it's quite pointless to add files in these directories in the ramdisk.
Changing files in the ramdisk from the boot image
Changing one or more properties
Warning:
Please note that I am not an expert on Android internals and the following may be completely wrong.
(Any comments or corrections are welcome)
There are some files with property definitions in the boot image:
Code:
ASUS_I006D:/data/adb/workdir/ramdisk # find . -name "*.prop"
./default.prop
./system/etc/ramdisk/build.prop
ASUS_I006D:/data/adb/workdir/ramdisk #
To change or add a property it should be sufficient to add or change it in the file default.prop in the ramdisk from the boot image. But that does not work (at least in my tests...)
So to change or add a property it must be added to the file
/system/etc/ramdisk/build.prop
in the ramdisk for the boot image.
For example to add a swap device with 2 GB in the OmniROM these properties can be used:
Code:
#
# define the size for the device zram0 (use the postfix G for values in Gigabytes or M for values in Megabytes)
#
vendor.zram.disksize=2147483648
vendor.zram.enable=1
The result after repacking and installing the boot image :
Code:
ASUS_I006D:/ # id
uid=0(root) gid=0(root) groups=0(root) context=u:r:magisk:s0
ASUS_I006D:/ #
ASUS_I006D:/data/adb/workdir/ramdisk # getprop vendor.zram.disksize
2147483648
ASUS_I006D:/data/adb/workdir/ramdisk # vendor.zram.enable
1
ASUS_I006D:/data/adb/workdir/ramdisk #
1|ASUS_I006D:/data/adb/workdir/ramdisk # free
total used free shared buffers
Mem: 7612493824 4858556416 2753937408 12169216 15933440
-/+ buffers/cache: 4842622976 2769870848
Swap: 2147479552 0 2147479552
ASUS_I006D:/data/adb/workdir/ramdisk #
Notes:
These new properties defined in the file /system/etc/ramdisk/build.prop in the ramdisk are only visible for the root user.
Most probably another SELinux definition in one of the *context* files in the boot image is required to make the property visible for all users (but I don't know the necessary permissions for the properties to make them visible for all user). The current SELinx context for these properties is defined in the file vendor_property_contexts in the root directory of the ramdisk from the boot image:
Code:
ASUS_I006D:/data/adb/workdir/ramdisk # grep zram vendor_property_contexts
vendor.zram.disksize u:object_r:vendor_exported_system_prop:s0
vendor.zram.enable u:object_r:vendor_exported_system_prop:s0
persist.vendor.zram u:object_r:vendor_mpctl_prop:s0
vendor.asus.zram u:object_r:vendor_mpctl_prop:s0
vendor.zram. u:object_r:vendor_mpctl_prop:s0
ASUS_I006D:/data/adb/workdir/ramdisk #
To add a new property without a specific SELInux context it seems to be sufficient to add the property to the file /system/etc/ramdisk/build.prop in the ramdisk from the boot image (this does not work for properties starting with vendor. ):
Code:
# add the property to the file
#
130|ASUS_I006D:/ # tail -3 /data/adb/workdir/ramdisk/system/etc/ramdisk/build.prop
build.mysettings.variable01.value=5555
#
# end of file
ASUS_I006D:/ #
After the reboot the property is visible for non-root user:
Code:
ASUS_I006D:/ $ id
uid=2000(shell) gid=2000(shell) groups=2000(shell),1004(input),1007(log),1011(adb),1015(sdcard_rw),1028(sdcard_r),1078(ext_data_rw),1079(ext_obb_rw),3001(net_bt_admin),3002(net_bt),3003(inet),3006(net_bw_stats),3009(readproc),3011(uhid),3012(readtracefs) context=u:r:shell:s0
ASUS_I006D:/ $
ASUS_I006D:/ $ getprop build.mysettings.variable01.value
5555
ASUS_I006D:/ $
But the new property can only be changed by the user root:
Code:
1|ASUS_I006D:/ $ id
uid=2000(shell) gid=2000(shell) groups=2000(shell),1004(input),1007(log),1011(adb),1015(sdcard_rw),1028(sdcard_r),1078(ext_data_rw),1079(ext_obb_rw),3001(net_bt_admin),3002(net_bt),3003(inet),3006(net_bw_stats),3009(readproc),3011(uhid),3012(readtracefs) context=u:r:shell:s0
ASUS_I006D:/ $
ASUS_I006D:/ $ setprop build.mysettings.variable01.value 7777
Failed to set property 'build.mysettings.variable01.value' to '7777'.
See dmesg for error reason.
1|ASUS_I006D:/ $
1|ASUS_I006D:/ $ su -
ASUS_I006D:/ #
ASUS_I006D:/ # id
uid=0(root) gid=0(root) groups=0(root) context=u:r:magisk:s0
ASUS_I006D:/ #
ASUS_I006D:/ # setprop build.mysettings.variable01.value 7777
ASUS_I006D:/ #
ASUS_I006D:/ # getprop build.mysettings.variable01.value
7777
ASUS_I006D:/ #
ASUS_I006D:/ # ^D
ASUS_I006D:/ $ id
uid=2000(shell) gid=2000(shell) groups=2000(shell),1004(input),1007(log),1011(adb),1015(sdcard_rw),1028(sdcard_r),1078(ext_data_rw),1079(ext_obb_rw),3001(net_bt_admin),3002(net_bt),3003(inet),3006(net_bw_stats),3009(readproc),3011(uhid),3012(readtracefs) context=u:r:shell:s0
ASUS_I006D:/ $ getprop build.mysettings.variable01.value
7777
ASUS_I006D:/ $
(see here https://source.android.com/docs/core/architecture/configuration/add-system-properties for details about defining properties)
When done with your changes repack the ramdisk.
First we recreate the cpio archive:
Code:
ASUS_I006D:/data/adb/workdir # cd /data/adb/workdir/ramdisk
ASUS_I006D:/data/adb/workdir/ramdisk #
ASUS_I006D:/data/adb/workdir/ramdisk # find . | cpio -o >../boot_files/ramdisk.cpio
ASUS_I006D:/data/adb/workdir/ramdisk #
ASUS_I006D:/data/adb/workdir/ramdisk # ls -l ../boot_files/ramdisk.cpio
-rw-r--r-- 1 root root 30865560 2022-09-18 18:31 ../boot_files/ramdisk.cpio
ASUS_I006D:/data/adb/workdir/ramdisk #
And then we recreate the boot image with the kernel and the changed ramdisk using magiskboot:
Code:
ASUS_I006D:/data/adb/workdir/ramdisk # cd /data/adb/workdir/boot_files/
ASUS_I006D:/data/adb/workdir/boot_files #
130|ASUS_I006D:/data/adb/workdir/boot_files # /data/adb/magisk/magiskboot repack ../boot_b.img ../boot_b.img.new
Parsing boot image: [../boot_b.img]
HEADER_VER [3]
KERNEL_SZ [42025472]
RAMDISK_SZ [15093897]
OS_VERSION [12.0.0]
OS_PATCH_LEVEL [2022-05]
PAGESIZE [4096]
CMDLINE []
KERNEL_FMT [raw]
RAMDISK_FMT [gzip]
VBMETA
Repack to boot image: [../boot_b.img.new]
HEADER_VER [3]
KERNEL_SZ [42025472]
RAMDISK_SZ [15094405]
OS_VERSION [12.0.0]
OS_PATCH_LEVEL [2022-05]
PAGESIZE [4096]
CMDLINE []
ASUS_I006D:/data/adb/workdir/boot_files #
ASUS_I006D:/data/adb/workdir/boot_files # ls -l ../boot_b.img ../boot_b.img.new
-rw-r--r-- 1 root root 100663296 2022-09-18 18:20 ../boot_b.img
-rw-r--r-- 1 root root 100663296 2022-09-18 18:34 ../boot_b.img.new
ASUS_I006D:/data/adb/workdir/boot_files #
The new boot image file can now be written to the boot partition (either via dd or fastboot):
Code:
ASUS_I006D:/data/adb/workdir # cd /data/adb/workdir
ASUS_I006D:/data/adb/workdir # dd if=./boot_b.img.new of=/dev/block/by-name/boot_b
196608+0 records in
196608+0 records out
100663296 bytes (96 M) copied, 5.324559 s, 18 M/s
ASUS_I006D:/data/adb/workdir #
That's it -- now the new boot image should be used for the next reboots of the phone.
Additional infos
Please note that the file /system/etc/ramdisk/build.prop does not exist in the ramdisk from the boot disk used in the Original Android 12 for the ASUS Zenfone 8 . So this approach to change the properties does not work in that OS.
But the general approach used in these instructions to change files in the ramdisk used for the boot image does also work in the Original Android 12 for the ASUS Zenfone 8.
In the OmniROM for the Zenfone 8 and also in the Original Android 10 for the Zenfone 8 the swap device is created and configured with this init script: /vendor/bin/init.asus.zram.sh
See here
How to disable or change the swap device in the Android 12 from ASUS for the Zenfone 8
for a method using Magisk to change the swap device config in the Original ASUS Android 12
See here
How to create a swap device in the OmniROM 12 using Magisk
for a method using Magisk to change the swap device config in the OnmiROM 12
Replace files in the root directory
Magisk also supports changing files in the root directory via an overlay system -- see the section Root Directory Overlay System in this page https://github.com/topjohnwu/Magisk/blob/master/docs/guides.md.
To use this feature it's also neccessary to unpack and repack the boot partition.
An example about how to use this feature is here:
Magisk overlay - execute a script or copy files
Another example is in this thread https://github.com/topjohnwu/Magisk/issues/2978
Including sample code to use magiskboot to change files in the ramdisk from the boot partition:
Code:
./magiskboot unpack boot_root.img
./magiskboot cpio ramdisk.cpio \
"mkdir 0700 overlay.d" \
"add 0700 overlay.d/init.custom.rc init.custom.rc" \
"mkdir 0700 overlay.d/sbin" \
"add 0700 overlay.d/sbin/custom.sh init.custom.sh"
./magiskboot repack boot_root.img
Another example for this techniquie is in this post:
How to enable access via adb on a new installed OS
Trouble Shooting
If the phone does not boot anymore with the changed boot partition restore the boot partition from the boot image file created at the beginning either via dd after booting from a recovery image like TWRP or using fastboot to flash the boot paritition.
It's important to at least unpack the cpio with the ramdisk contents on an Unix filesystem (e.g. ext3, ext4, etc) - this can not be done in the device mounted to /sdcard.
Instructions for cut & paste
The instructions below are for cut & paste. Be aware that there is no error checking.
Instructions to copy the boot partition to a boot image file and to unpack the boot image and the ramdisk
Code:
CUR_SLOT=$( getprop ro.boot.slot_suffix )
cd /data/adb
mkdir /data/adb/workdir
mkdir /data/adb/workdir/backup
mkdir /data/adb/workdir/ramdisk
mkdir /data/adb/workdir/boot_files
cd /data/adb/workdir
dd if=/dev/block/by-name/boot${CUR_SLOT} of=./boot${CUR_SLOT}.img
cp boot_b.img backup/
cd boot_files
/data/adb/magisk/magiskboot unpack ../boot${CUR_SLOT}.img
cd /data/adb/workdir/ramdisk
cpio -idm <../boot_files/ramdisk.cpio
pwd
ls -ltr
Instructions to repack the ramdisk and the boot image and to rewrite the boot partition
Code:
CUR_SLOT=$( getprop ro.boot.slot_suffix )
cd /data/adb/workdir/ramdisk/
find . | cpio -o >../boot_files/ramdisk.cpio
cd /data/adb/workdir/boot_files/
/data/adb/magisk/magiskboot repack ../boot${CUR_SLOT}.img ../boot${CUR_SLOT}.img.new
cd /data/adb/workdir
dd if=./boot${CUR_SLOT}.img.new of=/dev/block/by-name/boot${CUR_SLOT}
reboot
History
30.09.2022/bs
add infos about changing files in the root directory via Magisk overlays
02.11.2022/bs
see How to process Android boot image files on a PC running the Linux OS for instructions about using magiskboot on a machine running the Linux OS
30.12.2022 /bs
Changed the links in this post to match the title of the linked post
Added a link to the new post to enable adb access
Thank you man!!!!! I used to make use of the mkbootimg_tools, but that ended up throwing errors saying it can't find "mkbootimg" I'm so glad I found this you spared me a huge headache. It ended up working really damn well
Tested device:
BLU View 2
Android 10
Rooted with Magisk/Unlocked bl
Сan i patch the adbd binary with magisktool? If the answer is yes, then where is the adbd binary in ramdisk? Or do I need to use another tool?
I apologize for the stupid questions, I'm new to this field
nom_ said:
Сan i patch the adbd binary with magisktool? If the answer is yes, then where is the adbd binary in ramdisk? Or do I need to use another tool?
I apologize for the stupid questions, I'm new to this field
Click to expand...
Click to collapse
What do you want to achieve?
"adbd binary" is the adb daemon running on the phone? And your goal is to replace the adb daemon with a patched version?
regards
Bernd
bnsmb said:
What do you want to achieve?
"adbd binary" is the adb daemon running on the phone? And your goal is to replace the adb daemon with a patched version?
regards
Bernd
Click to expand...
Click to collapse
Yes, by this guide: https://harrisonsand.com/posts/patching-adb-root/
I want to use adb root, but it's throws this error "adb cannot run as root in production builds"
nom_ said:
Yes, by this guide: https://harrisonsand.com/posts/patching-adb-root/
I want to use adb root, but it's throws this error "adb cannot run as root in production builds"
Click to expand...
Click to collapse
Well , then just extract the boot image ; unpack the ramdisk , search for the adbd in the files from the ramdisk using
find <dir_with_unpacked_ramdisk> -name adbd
or something similar (in the ramdisk from the boot image for OmniROM 13 the adbd is in the directory ./system/bin/) ; patch the adbd binary, and recreate the ramdisk and the boot image as described above .
This must be done after every OS update so I recommend to better use Magisk for getting root access if possible.
regards
Bernd
bnsmb said:
Well , then just extract the boot image ; unpack the ramdisk , search for the adbd in the files from the ramdisk using
find <dir_with_unpacked_ramdisk> -name adbd
or something similar (in the ramdisk from the boot image for OmniROM 13 the adbd is in the directory ./system/bin/) ; patch the adbd binary, and recreate the ramdisk and the boot image as described above .
This must be done after every OS update so I recommend to better use Magisk for getting root access if possible.
regards
Bernd
Click to expand...
Click to collapse
Thank you Bernd)!
@nom_ - Were you able to make this work?
CC: @bnsmb
I believe post Android 11, all vendor-specific information is factored out of the boot partition and relocated into a new vendor_boot partition.[1]
I was able to extract the vendor_boot image using this, but curious as to how to boot via vendor_boot image?
If I flash it using fastboot, my device goes into a boot loop.
Code:
fastboot flash vendor_boot vendor_boot.img.
How can the /system/bin dir this be repacked within ramdisk as boot img?
[1] https://source.android.com/docs/core/architecture/partitions/vendor-boot-partitions
Rev_786 said:
@nom_ - Were you able to make this work?
CC: @bnsmb
I believe post Android 11, all vendor-specific information is factored out of the boot partition and relocated into a new vendor_boot partition.[1]
I was able to extract the vendor_boot image using this, but curious as to how to boot via vendor_boot image?
If I flash it using fastboot, my device goes into a boot loop.
Code:
fastboot flash vendor_boot vendor_boot.img.
How can the /system/bin dir this be repacked within ramdisk as boot img?
[1] https://source.android.com/docs/core/architecture/partitions/vendor-boot-partitions
Click to expand...
Click to collapse
HI
what do you want to achieve?
regards
Bernd
bnsmb said:
HI
what do you want to achieve?
regards
Bernd
Click to expand...
Click to collapse
Boot by adding custom system binaries in vendor_boot img
(For example, the patched adbd which is discussed)
Rev_786 said:
Boot by adding custom system binaries in vendor_boot img
(For example, the patched adbd which is discussed)
Click to expand...
Click to collapse
I doubt that replacing files in the vendor_boot.img can be done easily ... I recommend to use Magisk to do that:
https://forum.xda-developers.com/t/how-to-change-files-in-the-directory-system-with-magisk.4454489/
see the section beginning with "This method can also be used to replace files in the directories /vendor, /product, or /system_ext:"
If that does not work you might try this approach:
https://forum.xda-developers.com/t/how-to-change-files-in-the-directory-system-with-magisk.4454489/
regards
Bernd
I want to add custom.init.rc with this code
```
./magiskboot unpack boot_root.img
./magiskboot cpio ramdisk.cpio \
"mkdir 0700 overlay.d" \
"add 0700 overlay.d/init.custom.rc init.custom.rc" \
"mkdir 0700 overlay.d/sbin" \
"add 0700 overlay.d/sbin/custom.sh init.custom.sh"
./magiskboot repack boot_root.img
```
After reboot my phone doing nothing, check file /sbin/custom.sh is existed, but /init.custom.rc not exist.
A10 Pixel Experience Redmi4x
alfanveykov said:
I want to add custom.init.rc with this code
```
./magiskboot unpack boot_root.img
./magiskboot cpio ramdisk.cpio \
"mkdir 0700 overlay.d" \
"add 0700 overlay.d/init.custom.rc init.custom.rc" \
"mkdir 0700 overlay.d/sbin" \
"add 0700 overlay.d/sbin/custom.sh init.custom.sh"
./magiskboot repack boot_root.img
```
After reboot my phone doing nothing, check file /sbin/custom.sh is existed, but /init.custom.rc not exist.
A10 Pixel Experience Redmi4x
Click to expand...
Click to collapse
That work's like designed. Excerpt from the Magisk developer guide https://topjohnwu.github.io/Magisk/guides.html:
Each *.rc file (except for init.rc) in overlay.d will be read and concatenated AFTER init.rc if it does not exist in the root directory, otherwise it will REPLACE the existing one.
Click to expand...
Click to collapse
The *rc files will be read and processed while booting the Android OS -- Magisk will not copy them to the boot partition. And that make sense because the *rc files in Android are not used at all after the boot process finished.
To be able to test in the running Android OS if an additional *rc file is processed I recommend to add instructions to set a new property while booting the OS, e.g.:
Spoiler: cat init.custom.rc
Code:
ASUS_I006D:/data/develop # cat init.custom.rc
on property:bs.test.prop01=1
setprop bs.test.prop02 "1"
on property:bs.test.prop01=0
setprop bs.test.prop02 "0"
service test_service_001 /system/bin/sh /data/develop/init001.custom.sh
user root
group root
disabled
seclabel u:r:magisk:s0
oneshot
service test_service_002 /system/bin/sh ${MAGISKTMP}/init002.custom.sh
user root
group root
disabled
seclabel u:r:magisk:s0
oneshot
on property:bs.test.prop01=9
exec u:r:magisk:s0 -- /system/bin/sh /data/develop/init.custom001.sh 001
on property:bs.test.prop01=8
exec u:r:magisk:s0 -- /system/bin/sh ${MAGISKTMP}/init.custom002.sh 000
on property:bs.test.prop02=10
start test_service_001
on property:bs.test.prop02=20
start test_service_002
on early-init
setprop bs.test.prop01 "111"
setprop bs.test.prop02 "222"
ASUS_I006D:/data/develop #
The commands in the section "on early-init"
Code:
on early-init
setprop bs.test.prop01 "111"
setprop bs.test.prop02 "222"
can be used to check if the *rc file was processed:
Code:
ASUS_I006D:/ $ uptime
21:14:00 up 0 min, 0 users, load average: 1.86, 0.44, 0.14
ASUS_I006D:/ $ getprop bs.test.prop01
111
ASUS_I006D:/ $ getprop bs.test.prop02
222
ASUS_I006D:/ $
If the properties are not set the *rc file was not processed. Most probably there is a syntax error in that file.
And for the records:
Note that the new properties can only be read by non-root user; non-root users can not change them:
Code:
ASUS_I006D:/ $ id
uid=2000(shell) gid=2000(shell) groups=2000(shell),1004(input),1007(log),1011(adb),1015(sdcard_rw),1028(sdcard_r),1078(ext_data_rw),1079(ext_obb_rw),3001(net_bt_admin),3002(net_bt),3003(inet),3006(net_bw_stats),3009(readproc),3011(uhid),3012(readtracefs) context=u:r:shell:s0
ASUS_I006D:/ $ setprop bs.test.prop02 999
Failed to set property 'bs.test.prop02' to '999'.
See dmesg for error reason.
1|ASUS_I006D:/ $
The new property can only be changed by the user root:
Code:
ASUS_I006D:/ $ su - -c setprop bs.test.prop02 999
ASUS_I006D:/ $
ASUS_I006D:/ $ getprop bs.test.prop02
999
ASUS_I006D:/ $
To enable non-root user to change these new properties a correct SELinux context must be defined for the properties.
You should also be aware of this issue - again an excerpt from the Magisk Developer Guide https://topjohnwu.github.io/Magisk/guides.html:
Starting from Android 11, the /sbin folder may no longer exists, and in that scenario, Magisk randomly generates a different tmpfs folder each boot. Every occurrence of the pattern ${MAGISKTMP} in your *.rc scripts will be replaced with the Magisk tmpfs folder when magiskinit injects it into init.rc. On pre Android 11 devices, ${MAGISKTMP} will simply be replaced with /sbin, so NEVER hardcode /sbin in the *.rc scripts when referencing these additional files.
Click to expand...
Click to collapse
regards
Bernd

How To Guide How to run a script at shutdown

How to run a script at shutdown
To define additional startup scripts via Magisk the Magisk directories /data/adb/service.d and /data/adb/post-fs-data.d can be used. Unfortunately there is no equivalent for scripts that should be executed during shutdown.
So we must use other methods to implement these kind of scripts.
Using the overlay feature of Magisk to run a script at shutdown
Introduction
in Android it is possible to define actions that will be executed when certain conditions are satisfied.
These definitions are done in the file init.rc (and other .rc files) using the Android Init Language.
And this feature can be used to execute a command when the phone is shutting down.
Note:
For details about the Android Init Language used for these files see here https://android.googlesource.com/platform/system/core/+/master/init/README.md
The .rc files used by Android are in the directories
/system/etc/init​/vendor/etc/init​/odm/etc/init​
Note: The first .rc file read is /system/etc/init/hw/init.rc
Unfortunately it's useless to change the .rc files in these directories using the Magisk features to change files in the directory /system because these files are processed by the OS before the new files are "created" by Magisk.
Therefor the overlay functionality from Magisk must be used to create additional .rc files (see the section Root Directory Overlay System on this page https://github.com/topjohnwu/Magisk/blob/master/docs/guides.md for details about this Magisk Feature).
Preparation
To be able to restore the original boot partition in case of an error create an image of the original boot partition from the phone on your PC before starting the development:
Code:
CUR_SLOT=$( adb shell getprop ro.boot.slot_suffix )
adb shell su - -c dd if=/dev/block/by-name/boot${CUR_SLOT} | cat >boot${CUR_SLOT}
e.g.
Code:
[ OmniRomDev - [email protected] /data/develop/android/test ] $ CUR_SLOT=$( adb shell getprop ro.boot.slot_suffix )
[ OmniRomDev - [email protected] /data/develop/android/test ] $ echo ${CUR_SLOT}
_b
[ OmniRomDev - [email protected] /data/develop/android/test ] $
[ OmniRomDev - [email protected] /data/develop/android/test ] $ adb shell su - -c dd if=/dev/block/by-name/boot${CUR_SLOT} | cat >boot${CUR_SLOT}.img
196608+0 records in
196608+0 records out
100663296 bytes (96 M) copied, 2.668147 s, 36 M/s
[ OmniRomDev - [email protected] /data/develop/android/test ]
[ OmniRomDev - [email protected] /data/develop/android/test ] $ ls -ltr boot${CUR_SLOT}.img
-rw-r--r--. 1 xtrnaw7 xtrnaw7 100663296 Oct 1 12:13 boot_b.img
[ OmniRomDev - [email protected] /data/develop/android/test ] $
To trouble shoot issues with this approach it is highly recommended to create an Magisk init script in the directory
/data/adb/post-fs-data.d
to fetch and store the Android logs into a persistent file. Use these commands to create the script:
Code:
cat >/data/adb/post-fs-data.d/0002logcatboot <<-EOT
mkdir -p /cache/logs
# backup the OS logs from before the reboot:
#
[ -r /cache/logs/log ] && mv /cache/logs/log /cache/logs/oldlog
/system/bin/logcat -r 102400 -n 9 -v threadTime -f /cache/logs/log >/cache/logs/info.log 2>/cache/logs/err.log &
EOT
chmod 755 /data/adb/post-fs-data.d/0001logcatboot
Using this script the log messages from before the last reboot are stored in the file /cache/logs/oldlog.
To activate the script the phone must be rebooted.
Check the contents of the directory /cache/logs/log after the reboot as user root to be sure that it works.
Code:
[email protected]_I006D:/ $ su - -c ls -ltr /cache/logs
total 205008
-rw-rw-rw- 1 root root 0 1970-01-06 08:16 info.log
-rw-rw-rw- 1 root root 0 1970-01-06 08:16 err.log
-rw-r----- 1 root root 4707523 2022-10-01 17:29 log
[email protected]_I006D:/ $
Details
The trigger in the .rc files for the action that should be done while shutting down is
on shutdown
The trigger can be used more then once; the OS will execute all defined actions for the trigger in the order they are found in the rc files.
The action to run an executable in the .rc file is
exec [ <seclabel> [ <user> [ <group>\* ] ] ] -- <command> [ <argument>\* ]
Fork and execute command with the given arguments. The command starts after “--” so that an optional security context, user, and supplementary groups can be provided. No other commands will be run until this one finishes. seclabel can be a - to denote default. Properties are expanded within argument. Init halts executing commands until the forked process exits.
Click to expand...
Click to collapse
In Android SELinux is enabled by default. Therefor it's neccessary to use the correct SELinux context for the files used.
(Note: The SELinux context for the init process executing the action is u:r:init:0 )
It's quite difficult to find the correct SELinux contexts in Android for this approach therefor it's better to use the general SELinux context defined by Magisk: u:r:magisk:s0 .
Implementation
Note:
All commands must be done as user root in an session on the phone or in an adb session.
So first create the neccessary directories and files:
Code:
mkdir -p /data/init_scripts
mkdir -p /data/init_scripts/log
Create the script to execute on shutdown:
Code:
cat >/data/init_scripts/my_shutdown.sh <<-\EOT
#!/system/bin/sh
SHUTDOWN_LOG="/data/init_scripts/log/myshutdown.$$.log"
echo "$0: Shutdown with parameter \"$*\" started at $( date ) " >>${SHUTDOWN_LOG}
echo "*** id : " >>${SHUTDOWN_LOG} 2>&1
id >>${SHUTDOWN_LOG} 2>&1
# ... add necessary commands ...
EOT
chmod 755 /data/init_scripts/my_shutdown.sh
Correct the SELinux context:
Code:
chcon -R u:r:magisk:s0 /data/init_scripts/
Check the result
Code:
[email protected]_I006D:/ # find /data/init_scripts/ -exec ls -ld {} \;
drwxr-xr-x 3 root root u:r:magisk:s0 3452 2022-10-01 16:12 /data/init_scripts/
-rwxr-xr-x 1 root root u:r:magisk:s0 637 2022-10-01 16:12 /data/init_scripts/my_shutdown.sh
drwxr-xr-x 2 root root u:r:magisk:s0 3452 2022-10-01 16:16 /data/init_scripts/log
[email protected]_I006D:/ #
Create a working directory:
Code:
#
# create a working directory
#
mkdir -p /data/adb/workdir
cd /data/adb/workdir
Now create the additional .rc file:
Code:
#
# change the current directory to the working directory
#
cd /data/adb/workdir
cat >init.custom.rc <<-\EOT
on shutdown
exec u:r:magisk:s0 -- /system/bin/sh /data/init_scripts/my_shutdown.sh 0008
on early-init
setprop my_custom_rc_file loaded
EOT
Note:
The additional trigger for early-init is for testing the new .rc file (see the trouble shooting section below for details). Magisk supports more then one .rc file; the name of the .rc file is meaningless but the extension must be .rc.
And now add the new file to the ramdisk on the boot partition:
Code:
#
# change the current directory to the working directory
#
cd /data/adb/workdir
# get the current active slot
#
CURRENT_SLOT=$( getprop ro.boot.slot_suffix )
echo "The current active slot is: ${CURRENT_SLOT}"
# copy the boot partition from the active slot to a file
#
dd if=/dev/block/by-name/boot${CURRENT_SLOT} of=./boot_root.img
# unpack the image file
#
/data/adb/magisk/magiskboot unpack ./boot_root.img
# add the new dirs and files to the ramdisk from the boot partition
#
/data/adb/magisk/magiskboot cpio ramdisk.cpio \
"mkdir 0700 overlay.d" \
"add 0700 overlay.d/init.custom.rc init.custom.rc"
# recreate the image file for the boot partition
#
/data/adb/magisk/magiskboot repack boot_root.img
# write the corrected image file to the boot partition
#
dd if=./new-boot.img of=/dev/block/by-name/boot${CURRENT_SLOT}
Note:
The commands to unpack and pack the ramdisk manually using the cpio command are (if NOT using the Magisk binary magiskboot):
Code:
RAMDISK=$PWD/ramdisk
mkdir ${RAMDISK}
cd ${RAMDISK}
# unpack the ramdisk
#
cpio -idm <../ramdisk.cpio
# ... do what ever is necessary with the files/dirs in ${RAMDISK}
# pack the ramdisk again
#
cd ${RAMDISK}
find . | cpio -o >../ramdisk.cpio
Now reboot the phone to activate the new .rc config and after the reboot check that the .rc file was processed
Code:
getprop my_custom_rc_file
e.g
Code:
[email protected]_I006D:/ $ getprop my_custom_rc_file
loaded
[email protected]_I006D:/ $
If the property defined in the .rc file, my_custom_rc_file, is not set something went wrong and you should check the OS logs and double check your config.
If the new property is defined you can test the shutdown action by rebooting the phone again.
While doing this reboot the new shutdown script should be executed and after the reboot is done there should be the log file from the shutdown script:
Code:
[email protected]_I006D:/ $ su -
[email protected]_I006D:/ # ls -l /data/init_scripts/log
total 0
-rw------- 1 root root 179 2022-10-01 18:23 myshutdown.4617.log
[email protected]_I006D:/ # cat /data/init_scripts/log/myshutdown.4617.log
/data/init_scripts/my_shutdown.sh: Shutdown with parameter "0008" started at Sat Oct 1 18:23:14 CEST 2022
*** id :
uid=0(root) gid=0(root) groups=0(root) context=u:r:magisk:s0
[email protected]_I006D:/ #
That's it.
Note that you can change the script executed while doing the shutdown without changing the boot image again.
But you should always test the script before rebooting -- an error in your script may stop the reboot.
To change the additional .rc files it's necessary to recreate the ramdisk and boot partition.
The filesystems for /data and for /sdcard are still mounted while executing the actions for the trigger "on shutdown" .
To log the current environment while executing the shutdown script you can add code like this to the script:
Code:
(
echo
echo "*** Environment while executing the shutdown script ..."
echo
echo "*** pwd: "
pwd
echo
echo "*** id: "
id
echo
echo "*** df -h: "
df -h
echo
echo "*** ps -efZ : "
ps -efZ
echo
echo "*** env: "
env
echo
echo "*** set: "
set
echo
) >>/data/init_scripts/log/myshutdown_env.log 2>&1
To create a directory in which other actions from the .rc file (like write) can write with SELinux enabled use one of the SELInux contexts the init process can write to, e.g:
Code:
mkdir /data/system_data
chcon u:object_r:system_data_file:s0 /data/system_data
Now the .rc config
Code:
on shutdown
write /data/system_data/myshutdown.log Shutdown_started\n
will work.
See the file ./plat_file_contexts in the ramdisk from the boot partition for other existing SELinux contexts, e.g.:
Code:
[email protected]_I006D:/data/adb/test # /data/adb/magisk/magiskboot cpio ramdisk.cpio "extract plat_file_contexts plat_file_contexts" <
Loading cpio: [ramdisk.cpio]
Extract [plat_file_contexts] to [plat_file_contexts]
[email protected]_I006D:/data/adb/test # ls -l plat_file_contexts
-rw-r--r-- 1 root root 40490 2022-10-03 16:27 plat_file_contexts
[email protected]_I006D:/data/adb/test #
Please be aware that these changes will be gone after the next OS update. But on the other hand it's quite easy to create a script to re-install the shutdown script without user intervention.
Trouble Shooting
The main reason for problems with this approach are invalid SELinux contexts. Therefor you should test your script in permissive SELinux mode if it does not work like expected. To do that temporary disable SELinux before rebooting (SELinux will be automatically enabled again after the reboot), e.g.:
Code:
# set SELinux to permissive
#
setenforce 0
reboot
and check the log messages in the directory /cache/logs/oldlog for SELinux related messages:
Code:
su - -c grep deny /cache/logs/oldlog
Note that you can not disable SELinux in an action in an .rc file.
To check if your additional .rc file is processed by Magisk add a statement like these to the custom .rc file in the overlay directory:
Code:
on early-init
setprop sys.example.foo bar
If this statement is processed by Magisk and Android the property sys.example.foo should be defined after the reboot, e.g.:
Code:
[email protected]_I006D:/ # getprop sys.example.foo
bar
[email protected]_I006D:/ #
To check if the "on shutdown" trigger is processed use :
Code:
on shutdown
write /sdcard/Download/myshutdown.log Shutdown_started\n
and reboot with disabled SELinux:
Code:
setenforce 0
reboot
If the "on shutdown" trigger in your .rc file is processed there should exist the file
/sdcard/Download/myshutdown.log
after the reboot
If the shutdown of the phone hangs open another adb session to the phone and kill the script (the adb daemon should still run while the shutdown script is running).
If the phone does not boot anymore with the new shutdown script reboot the phone from the TWRP image and fix / delete the new shutdown script. Or reflash the boot partition with the image file created before starting the development.
In general you should carefully check your .rc file for syntax errors -- entries in the file after the first syntax error will be ignored
Useful URLs
I used ideas and code from the web pages listed below for this HowTo:
How to run an executable on boot and keep it running?
How to run an Android init service with superuser SELinux context?
Magisk overlay - execute a script or copy files
History
03.10.2022 /bs
added code about to extract a single file (plat_file_contexts) from the ramdisk cpio image using magiskboot

How To Guide How to install TWRP via script

How to install TWRP via script
The recovery image TWRP is very useful for the maintenance of the Android OS. You can either boot the phone from the TWRP image without installing it using these commands:
Bash:
adb reboot bootloader
sudo fastboot boot ./twrp-3.7.0_12-0-I006D.img
or install the TWRP image into the boot partition and use the command
Bash:
adb reboot recovery
or
Bash:
sudo fastboot boot recovery
to boot into TWRP. Depending on the OS used there is also an option in the reboot dialog in the GUI to reboot into the recovery.
While the phone is booted from TWRP you can open a shell as user root via adb.
The only official method to install TWRP into the boot partition of the phone is via the TWRP GUI, e.g.:
boot the phone from the TWRP image (see above)
install TWRP into the boot partition using the menu entry "Advanced" and then "Flash Current TWRP". TWRP will then install itself into both boot partitions.
There is no method to install TWRP without user interaction via a script (at least I did not found any ...). Therefor I wrote a shell script to install TWRP without user input:
install_twrp_from_within_twrp.sh
The script install_twrp_from_within_twrp.sh can be used to install TWRP either into a boot partition or into an image file for the boot partition. The script must be executed in a shell on the phone while the phone is booted from the TWRP image that should be installed.
The usage of the script is:
Code:
ASUS_I006D:/data/local/tmp $ ./install_twrp_from_within_twrp.sh -h
install_twrp_from_within_twrp.sh - script to install TWRP into a boot partition or into a file
Usage:
install_twrp_from_within_twrp.sh [-f] [boot_image_file] [new_boot_image_file]
boot_image can be either an image file from the boot partition or a boot partition block device
(e.g. /dev/block/by-name/boot_a)
new_boot_partition_file must be the absolute name of a file.
Both parameter are optional
If the script is called without a parameter TWRP will be installed in the current boot partition.
If boot_image_file is a block device and new_boot_image_file is missing TWRP will be installed in the block device.
If the parameter new_boot_image_file is used the script will only write a boot partition image with TWRP into that file.
Use the parameter -f to ignore missing or invalid checksums.
This script must run in a shell in TWRP
Environment variables used by the script if set:
BIN_DIR (Current value: "/system/bin")
TMPDIR (Current value: "/data/local/tmp")
|ASUS_I006D:/data/local/tmp $
The commands used in the script install_twrp_from_within_twrp.sh to install TWRP are copied from the TWRP source file with the code to install TWRP:
https://github.com/TeamWin/android_bootable_recovery/blob/android-12.1/twrpRepacker.cpp
Note that TWRP contains a copy of the binary magiskboot to unpack and repack the boot partition. Therefor the installation should work on all phones that are supported by Magisk.
Be aware that the installation of TWRP will wipe out the installation of Magisk (or any other tool for enabling root access). So for installing TWRP and Magisk they must be installed in this order:
install TWRP
install Magisk (or a similar tool)
Example usage:
Code:
ASUS_I006D:/ # /cache/install_twrp_from_within_twrp.sh /dev/block/by-name/boot_b
Installing TWRP into a boot image or boot partition via script
Checking the running OS ...
OK, running a shell in TWRP: "twrp_I006D" version "3.7.0_12-0"
Checking the prerequisites for installing TWRP ...
Using the partition "/dev/block/by-name/boot_b" as source for the installation of TWRP
Creating the new boot image with TWRP in the file "/data/local/tmp/img.568/new-boot.img"
Checking if the required executables exist ...
OK, the file "/system/bin/magiskboot" exists and is executable
OK, the file "/system/bin/cpio" exists and is executable
OK, the file "/system/bin/sha256sum" exists and is executable
OK, the file "/system/bin/getprop" exists and is executable
OK, the file "/system/bin/dd" exists and is executable
Checking if the requried data files exist ...
OK, the file "/ramdisk-files.sha256sum" exists
OK, the file "/ramdisk-files.txt" exists
OK, the file "/dev/block/by-name/boot_b" exists
Checking the check sums of the files for the new ramdisk ...
OK, the check sums of the files for the new ramdisk are okay
Directory "/data/local/tmp" successfully created
Directory "/data/local/tmp/img.568" successfully created
Directory "/data/local/tmp/img_files.568" successfully created
The temporary directory to unpack the boot image is "/data/local/tmp/img_files.568"
Unpacking the boot image from "/dev/block/by-name/boot_b" ...
Parsing boot image: [/dev/block/by-name/boot_b]
HEADER_VER [3]
KERNEL_SZ [42027520]
RAMDISK_SZ [34080747]
OS_VERSION [12.0.0]
OS_PATCH_LEVEL [2022-05]
PAGESIZE [4096]
CMDLINE []
KERNEL_FMT [raw]
RAMDISK_FMT [gzip]
VBMETA
OK, "/dev/block/by-name/boot_b" successfully unpacked to "/data/local/tmp/img_files.568" :
Creating a backup of the original ramdisk ...
total 74412
-rw-rw-rw- 1 root root 50 2022-10-24 19:35 header
-rw-r--r-- 1 root root 42027520 2022-10-24 19:35 kernel
-rw-r--r-- 1 root root 34080747 2022-10-24 19:35 ramdisk.cpio.org
Creating the new ramdisk with TWRP ...
New ramdisk with TWRP "/data/local/tmp/img_files.568/ramdisk.cpio" successfully created.
-rw-rw-rw- 1 root root 85852380 2022-10-24 19:35 /data/local/tmp/img_files.568/ramdisk.cpio
-rw-r--r-- 1 root root 34080747 2022-10-24 19:35 /data/local/tmp/img_files.568/ramdisk.cpio.org
Repacking the boot image into the file "/data/local/tmp/img.568/new-boot.img" ...
+ cd /data/local/tmp/img_files.568
+ /system/bin/magiskboot repack /dev/block/by-name/boot_b /data/local/tmp/img.568/new-boot.img
Parsing boot image: [/dev/block/by-name/boot_b]
HEADER_VER [3]
KERNEL_SZ [42027520]
RAMDISK_SZ [34080747]
OS_VERSION [12.0.0]
OS_PATCH_LEVEL [2022-05]
PAGESIZE [4096]
CMDLINE []
KERNEL_FMT [raw]
RAMDISK_FMT [gzip]
VBMETA
Repack to boot image: [/data/local/tmp/img.568/new-boot.img]
HEADER_VER [3]
KERNEL_SZ [42027520]
RAMDISK_SZ [34080769]
OS_VERSION [12.0.0]
OS_PATCH_LEVEL [2022-05]
PAGESIZE [4096]
CMDLINE []
+ TEMPRC=0
+ set +x
OK, the new boot image "/data/local/tmp/img.568/new-boot.img" successfully created
-rw-r--r-- 1 root root 100663296 2022-10-24 19:35 /data/local/tmp/img.568/new-boot.img
Now rewriting "/dev/block/by-name/boot_b" using "/data/local/tmp/img.568/new-boot.img" ...
196608+0 records in
196608+0 records out
100663296 bytes (96 M) copied, 4.498630 s, 21 M/s
TWRP successfully installed in "/dev/block/by-name/boot_b"
ASUS_I006D:/ #
To install TWRP using the script without user input these steps are neccessary:
reboot the phone into the bootloader
boot the phone from the TWRP image that should be installed on the phone
copy the script install_twrp_from_within_twrp.sh to the phone
execute the script install_twrp_from_within_twrp.sh on the phone in an adb shell
To automate these steps I wrote a wrapper script :
install_twrp.sh
The wrapper script install_twrp.sh must be executed on a machine running Linux with the phone attached via USB.
The wrapper script will check the current status of the phone, boot the phone from the TWRP image, copy the script install_twrp_from_within_twrp.sh to the phone and execute it on the phone to install TWRP into either the active or the inactive boot partition.
The script install_twrp_from_within_twrp.sh must be in the same directory as install_twrp.sh (if not set the variable TWRP_INSTALL_SCRIPT before executing the script -- see the script usage below).
The usage for the script install_twrp.sh is:
Code:
[[email protected] /data/develop/android/scripts_on_linux]$ ./install_twrp.sh -h
./install_twrp.sh version - 1.0.0.0 - install TWRP to the boot partition of a phone running Android using TWRP
Usage
install_twrp_via_twrp.sh [boot_slot] [wait=n] [dd|fastboot] [twrp_image]
All parameter are optional
The parameter "boot_slot" can be a, b, active, inactive, next, current; default is the current boot slot of the phone
Use the parameter "dd" to request repatching via dd in an adb session ; use the parameter "fastboot" to request repatching via "fastboot"
Default is to use "dd" to flash the patched boot image
The value for the parameter "wait" is the number of seconds to wait before starting the script "install_twrp_from_within_twrp.sh" on the phone
This seems to be necessary to avoid errors while repacking the boot image. The default wait time is 10 seconds.
The parameter "twrp_image" can be used to define another TWRP image to use. The parameter is optional - the
default for "twrp_image" is hardcoded in the script (variable TWRP_IMAGE)
The default TWRP image of the script is the TWRP for the ASUS Zenfone 8.
The phone to patch must be attached via USB.
The phone can be either in fastboot mode, in normal mode with enabled adb support, or already booted from the TWRP image
The script uses the script "install_twrp_from_within_twrp.sh" to install TWRP. The script install_twrp_from_within_twrp.sh must
be in the same directory as this script. The script will be copied to the phone and then executed on the phone.
Set the variable TWRP_INSTALL_SCRIPT to the name of the script to use before starting this script if another script should be used .
To change some of the values used by the script you can set environment variables before starting the script:
Set the environment variable REBOOT to "yes" before starting the script to automatically reboot the phone after patching the new image
Set the environment variable REBOOT to "no" before starting the script to disable the automatic reboot after patching the new image.
Set the environment variable SERIAL_NUMBER to the serial number of the phone to patch if there is more then one phone connected via USB
Set the environment variable ADB_OPTIONS to the options to be used with the adb command
Set the environment variable FASTBOOT_OPTIONS to the options to be used with the fastboot command
Set the environment variable TMP_DIR_ON_THE_PHONE to the temporary directory to use on the phone
The default TWRP image to use is "/data/backup/ASUS_ZENFONE8/twrp/twrp-3.7.0_12-0-I006D.img"
The default script executed on the phone to install TWRP is "./install_twrp_from_within_twrp.sh"
[[email protected] /data/develop/android/scripts_on_linux]$
Without any parameter the script install_twrp.sh will install TWRP into the active boot partition.
Example:
Code:
[[email protected] /data/develop/android/scripts_on_linux]$ ./install_twrp.sh
./install_twrp.sh version - 1.0.0.0 - install TWRP to the boot partition of a phone running Android using TWRP
Using the TWRP image hardcoded in the script: "/data/backup/ASUS_ZENFONE8/twrp/twrp-3.7.0_12-0-I006D.img"
Checking the script prerequisites ...
Will wait 10 second(s) before starting the script on the phone
The script is running as user "xtrnaw7" -- will use "sudo" for the fastboot commands ...
Will patch the boot partition on the attached phone with the serial number "M6AIB760D0939LX"
Using the options "-d -s M6AIB760D0939LX " for the adb commands
Using the options " -s M6AIB760D0939LX " for the fastboot commands
Checking for a connected phone booted into fastboot mode ...
No attached phone in fastboot mode found
Checking for an attached phone with working access via adb (USB) ...
Linux localhost 5.4.147-Omni-qgki-perf-gea6f815f5af9-dirty #46 SMP PREEMPT Sat Oct 15 08:38:07 CEST 2022 aarch64
... found a phone connected via USB with working adb access
The phone is booted in normal mode
Booting the phone into the fastboot mode now ...
Waiting up to 60 seconds for the boot into the fastboot mode ...
Booting the phone from the TWRP image "/data/backup/ASUS_ZENFONE8/twrp/twrp-3.7.0_12-0-I006D.img" now ...
Sending 'boot.img' (98304 KB) OKAY [ 2.500s]
Booting OKAY [ 10.440s]
Finished. Total time: 12.983s
Waiting up to 60 seconds for the boot of the phone ....
Retrieving the current boot slot from the phone ...
The current boot slot is "_a"
The boot slot to patch is "_a"
The boot partition to patch is "boot_a"
Checking if the directory "/data/local/tmp" exists on the phone ....
/data/local/tmp
Copying the script "./install_twrp_from_within_twrp.sh" to the phone ...
./install_twrp_from_within_twrp.sh: 1 file pushed, 0 skipped. 216.6 MB/s (13141 bytes in 0.000s)
Creating the boot image file "/data/local/tmp/boot_a.327964.img" from the partition "/dev/block/by-name/boot_a" ...
196608+0 records in
196608+0 records out
100663296 bytes (96 M) copied, 0.311720 s, 308 M/s
Checking the result ...
-rw-rw-rw- 1 root root 100663296 2022-10-24 18:02 /data/local/tmp/boot_a.327964.img
The check sums are:
The check sum of the boot partition "/dev/block/by-name/boot_a" on the phohe is "728455636"
The check sum of the boot image file on the phone is "/data/local/tmp/boot_a.327964.img" is "728455636"
Installing TWRP using the boot image file "/data/local/tmp/boot_a.327964.img" ...
----------------------------------------------------------------------
[2022.10.24 20:02:43] Waiting now 10 seconds ...
+ adb -d -s M6AIB760D0939LX shell /data/local/tmp/install_twrp_from_within_twrp.sh /data/local/tmp/boot_a.327964.img /data/local/tmp/boot_a_witn_twrp.327964.img
Installing TWRP into a boot image or boot partition via script
Checking the running OS ...
OK, running a shell in TWRP: "twrp_I006D" version "3.7.0_12-0"
Checking the prerequisites for installing TWRP ...
Using the file "/data/local/tmp/boot_a.327964.img" as source for the installation of TWRP
Creating the boot image with TWRP in the file "/data/local/tmp/boot_a_witn_twrp.327964.img"
Checking if the required executables exist ...
OK, the file "/system/bin/magiskboot" exists and is executable
OK, the file "/system/bin/cpio" exists and is executable
OK, the file "/system/bin/sha256sum" exists and is executable
OK, the file "/system/bin/getprop" exists and is executable
Checking if the requried data files exist ...
OK, the file "/ramdisk-files.sha256sum" exists
OK, the file "/ramdisk-files.txt" exists
OK, the file "/data/local/tmp/boot_a.327964.img" exists
Checking the check sums of the files for the new ramdisk ...
OK, the check sums of the files for the new ramdisk are okay
Directory "/data/local/tmp" successfully created
Directory "/data/local/tmp/img.583" successfully created
Directory "/data/local/tmp/img_files.583" successfully created
The temporary directory to unpack the boot image is "/data/local/tmp/img_files.583"
Unpacking the boot image from "/data/local/tmp/boot_a.327964.img" ...
Parsing boot image: [/data/local/tmp/boot_a.327964.img]
HEADER_VER [3]
KERNEL_SZ [42025472]
RAMDISK_SZ [34080743]
OS_VERSION [12.0.0]
OS_PATCH_LEVEL [2022-05]
PAGESIZE [4096]
CMDLINE []
KERNEL_FMT [raw]
RAMDISK_FMT [gzip]
VBMETA
OK, "/data/local/tmp/boot_a.327964.img" successfully unpacked to "/data/local/tmp/img_files.583" :
Creating a backup of the original ramdisk ...
total 74412
-rw-rw-rw- 1 root root 50 2022-10-24 18:02 header
-rw-r--r-- 1 root root 42025472 2022-10-24 18:02 kernel
-rw-r--r-- 1 root root 34080743 2022-10-24 18:02 ramdisk.cpio.org
Creating the new ramdisk with TWRP ...
New ramdisk with TWRP "/data/local/tmp/img_files.583/ramdisk.cpio" successfully created.
-rw-rw-rw- 1 root root 85852380 2022-10-24 18:02 /data/local/tmp/img_files.583/ramdisk.cpio
-rw-r--r-- 1 root root 34080743 2022-10-24 18:02 /data/local/tmp/img_files.583/ramdisk.cpio.org
Repacking the boot image into the file "/data/local/tmp/boot_a_witn_twrp.327964.img" ...
+ cd /data/local/tmp/img_files.583
+ /system/bin/magiskboot repack /data/local/tmp/boot_a.327964.img /data/local/tmp/boot_a_witn_twrp.327964.img
Parsing boot image: [/data/local/tmp/boot_a.327964.img]
HEADER_VER [3]
KERNEL_SZ [42025472]
RAMDISK_SZ [34080743]
OS_VERSION [12.0.0]
OS_PATCH_LEVEL [2022-05]
PAGESIZE [4096]
CMDLINE []
KERNEL_FMT [raw]
RAMDISK_FMT [gzip]
VBMETA
Repack to boot image: [/data/local/tmp/boot_a_witn_twrp.327964.img]
HEADER_VER [3]
KERNEL_SZ [42025472]
RAMDISK_SZ [34080758]
OS_VERSION [12.0.0]
OS_PATCH_LEVEL [2022-05]
PAGESIZE [4096]
CMDLINE []
+ TEMPRC=0
+ set +x
OK, the new boot image "/data/local/tmp/boot_a_witn_twrp.327964.img" successfully created
-rw-r--r-- 1 root root 100663296 2022-10-24 18:03 /data/local/tmp/boot_a_witn_twrp.327964.img
Note: Flashing the new image to the boot partition was not requested
+ set +x
----------------------------------------------------------------------
Checking the result ...
The patched boot image is "/data/local/tmp/boot_a_witn_twrp.327964.img"
-rw-r--r-- 1 root root 100663296 2022-10-24 18:03 /data/local/tmp/boot_a_witn_twrp.327964.img
[2022.10.24 20:03:05] Waiting now 5 seconds ...
Patching the partition "/dev/block/by-name/boot_a" from the patched boot image file "/data/local/tmp/boot_a_witn_twrp.327964.img" via dd ...
196608+0 records in
196608+0 records out
100663296 bytes (96 M) copied, 4.865411 s, 20 M/s
Checking the result ....
The check sums for the images and devices on the phone are:
Checksum Size File/Device name
-------------------------------------
728455636 100663296 /data/local/tmp/boot_a.327964.img
2360878166 100663296 /data/local/tmp/boot_a_witn_twrp.327964.img
2360878166 100663296 /dev/block/by-name/boot_a
OK, patching the boot partition "/dev/block/by-name/boot_a" was successfull
*** Press return to reboot the phone now
Rebooting the phone now ...
[[email protected] /data/develop/android/scripts_on_linux]$
Advanced Usage
To install TWRP and Magisk via script these commands can be used (for example after an OS upgrade) :
Bash:
# install the Magisk App (if not already done ...)
#
cat Magisk-25.1_25100.apk | adb shell pm install -S "$( ls -l Magisk-25.1_25100.apk | awk '{ print $5}' )"
# install TWRP and Magisk into the boot partition
#
REBOOT=no ./install_twrp.sh ; REBOOT=yes ./install_magisk_via_twrp.sh
To install a new OS image including TWRP and Magisk these commands can be used:
Bash:
# boot the phone into the boot loader
#
adb reboot bootloader
# boot the phone from the TWRP image
#
sudo fastboot boot /data/backup/ASUS_ZENFONE8/twrp/twrp-3.7.0_12-0-I006D.img
# copy the OS image to install to the phone
#
adb push /data/develop/android/OmniROM/out/target/product/zenfone8/omni-12-20221015-zenfone8-MICROG.zip /sdcard/Download/
# install the OS image
#
adb shell twrp install /sdcard/Download/omni-12-20221015-zenfone8-MICROG.zip
# reboot into the new OS
#
adb shell twrp reboot
# install the Magisk app
#
cat Magisk-v25.2.apk | adb shell pm install -S "$( ls -l Magisk-v25.2.apk | awk '{ print $5}' )"
# install TWRP and Magisk
#
REBOOT=no ./install_twrp.sh ; REBOOT=yes ./install_magisk_via_twrp.sh
The documentation for the script install_magisk_via_twrp.sh can be found here:
How to install Magisk into the boot partition using a script.
Details
The script install_twrp_from_within_twrp.sh was tested on an ASUS Zenfone 8 with
OmniROM 12 (Android 12) and TWRP 3.7.0.12
OmniROM 12 (Android 12) and TWRP 3.6.1.12
Original Android 12 from ASUS and TWRP 3.7.0.12
OmniROM 13 (Android 13) and TWRP 3.7.0.12 (see note below)
Important Update 04.12.2022 /bs
In TWRP installed in the boot partition of an ASUS Zenfone 8 running early versions of OmniROM 13 the touch screen does not work. You can only use TWRP in an adb session in this configuration.
This bug was fixed in OmniROM 13 from 04.12.2022.
To get around this bug boot the phone from the image file with TWRP, e.g.:
Bash:
sudo fastboot boot twrp-3.7.0_12-0-I006D.img
or, better, update OmniROM 13 to the image from 04.12.2022 or later.
The script install_twrp_from_within_twrp.sh does not create a backup of the boot partition before rewriting it.
The script install_twrp_from_within_twrp.sh creates temporary files in the directory ${TMPDIR} on the phone; the default value for this variable in the script is
Bash:
TMPDIR="${TMPDIR:=/cache/install_twrp.$$}"
The default value for the variable in the tested TWRP versions is /data/local/tmp so without changes the temporary files will be created in that directory.
The script does not delete the temporary files so a manual cleanup of the directory might be necessary .
Trouble Shooting
For unknown reasons repacking the boot image fails sometimes and the script ends with an error message like this:
Code:
ERROR: The size of the new boot image file is 56713216 but the size of the original image file is 100663296 -- that does not match (RC=33)
To avoid this error increase the wait time using the script parameter "wait=n" (the default wait time is 10 seconds).
If increasing the wait time does not help just restart the wrapper script install_twrp.sh again while the phone is still booted from the TWRP image. So a workaround for this problem is :
Bash:
install_twrp.sh ; [ $? = 33 ] && install_twrp.sh
The following error message appears when executing the script install_twrp_from_within_twrp.sh after booting the already installed TWRP:
Code:
ERROR: Error checking the check sums of the files for the new ramdisk
./system/etc/fstab.postinstall: FAILED
Installing TWRP via script only works if the phone is booted from the TWRP image.
To ignore this error the parameter -f can be used - but this is NOT recommended.
Notes:
see here on How to install Magisk into the boot partition via script
[added 29.10.2022/bs]
see here for How to add additional files to the TWRP image

How To Guide How to change the kernel boot parameter for the Android kernel

While trying to get TWRP to boot on a phone with LIneageOS 20.x installed, I found some information about the boot parameters for the Android OS, which I document with this forum post.
To view the current kernel parameter for the Android kernel the command
Code:
cat /proc/cmdline
can be used. e.g
Code:
1|ASUS_I006D:/ $ su - -c cat /proc/cmdline
cgroup_disable=pressure log_buf_len=256K earlycon=msm_geni_serial,0x98c000 rcupdate.rcu_expedited=1 rcu_nocbs=0-7 kpti=off noirqdebug androidboot.console=ttyMSM0 androidboot.hardware=qcom androidboot.memcg=1 androidboot.usbcontroller=a600000.dwc3 cgroup.memory=nokmem,nosocket console=ttyMSM0,115200n8 ip6table_raw.raw_before_defrag=1 iptable_raw.raw_before_defrag=1 loop.max_part=7 lpm_levels.sleep_disabled=1 msm_rtb.filter=0x237 pcie_ports=compat service_locator.enable=1 swiotlb=0 kpti=off buildvariant=userdebug androidboot.verifiedbootstate=orange androidboot.keymaster=1 androidboot.bootdevice=1d84000.ufshc androidboot.fstab_suffix=default androidboot.boot_devices=soc/1d84000.ufshc androidboot.serialno=M6AIB760D0939LX androidboot.baseband=msm msm_drm.dsi_display0=qcom,mdss_dsi_samsung_fhd_cmd: androidboot.slot_suffix=_b rootwait ro init=/init androidboot.dtbo_idx=0 androidboot.dtb_idx=0 androidboot.force_normal_boot=1 androidboot.pre-ftm=0 androidboot.id.prj=4 androidboot.id.stage=7 androidboot.id.sku=3 androidboot.id.rf=1 androidboot.id.pcb=4731 androidboot.id.nfc=1 androidboot.country_code=EU androidboot.bootcount=0 androidboot.rawdump_en=0 androidboot.asus.authorized=0 androidboot.cpuid.hash=551c6708e291a3a57e013f5bdf2afe4a androidboot.toolid=15715839e737449088fe70f7faf618f0 SB=Y androidboot.fused=1 SBNR=Y androidboot.fused.norpmb=1 androidboot.id.panel=1 androidboot.id.ufs=3 androidboot.factory.crc=0x4FE99984 androidboot.ddr.manufacturer_id=FF androidboot.ddr.device_type=8 LCD=AC0E0041 androidboot.bootreason=hard
ASUS_I006D:/ $
Additional boot parameter can be defined in the boot partition. To do this the Magisk binary magiskboot can be used; Example (for doing this in an Android shell):
Code:
#
# the commands must be done as user root
#
ASUS_I006D:/ $ su -
ASUS_I006D:/ # mkdir /data/develop
ASUS_I006D:/ # cd /data/develop
ASUS_I006D:/data/develop # getprop ro.boot.slot_suffix
_b
ASUS_I006D:/data/develop #
#
# unpack the current boot partition to the current directory
#
# Note: The parameter -h for magiskboot is required to write the header file
#
ASUS_I006D:/data/develop # /data/adb/magisk/magiskboot unpack -h /dev/block/by-name/boot_b
Parsing boot image: [/dev/block/by-name/boot_b]
HEADER_VER [4]
KERNEL_SZ [39909888]
RAMDISK_SZ [43610592]
OS_VERSION [13.0.0]
OS_PATCH_LEVEL [2023-05]
PAGESIZE [4096]
CMDLINE []
KERNEL_FMT [raw]
RAMDISK_FMT [lz4_legacy]
VBMETA
ASUS_I006D:/data/develop #
ASUS_I006D:/data/develop # ls -l
total 129960
-rw-rw-rw- 1 root root 50 2023-06-25 14:31 header
-rw-r--r-- 1 root root 39909888 2023-06-25 14:31 kernel
-rw-r--r-- 1 root root 93031052 2023-06-25 14:31 ramdisk.cpio
ASUS_I006D:/data/develop #
ASUS_I006D:/data/develop # cat header
cmdline=
os_version=13.0.0
os_patch_level=2023-05
ASUS_I006D:/data/develop #
To define additional boot parameter add them to the line cmdline= in the file header and repack the boot image, e.g:
Code:
ASUS_I006D:/data/develop # sed -i -e "s/cmdline=/cmdline=debug /g" header
ASUS_I006D:/data/develop #
ASUS_I006D:/data/develop # cat header
cmdline=debug
os_version=13.0.0
os_patch_level=2023-05
ASUS_I006D:/data/develop #
ASUS_I006D:/data/develop # /data/adb/magisk/magiskboot repack /dev/block/by-name/boot_b ../new_boot.img
Parsing boot image: [/dev/block/by-name/boot_b]
HEADER_VER [4]
KERNEL_SZ [39909888]
RAMDISK_SZ [43610592]
OS_VERSION [13.0.0]
OS_PATCH_LEVEL [2023-05]
PAGESIZE [4096]
CMDLINE []
KERNEL_FMT [raw]
RAMDISK_FMT [lz4_legacy]
VBMETA
Repack to boot image: [../new_boot.img]
HEADER_VER [4]
KERNEL_SZ [39909888]
RAMDISK_SZ [43610592]
OS_VERSION [13.0.0]
OS_PATCH_LEVEL [2023-05]
PAGESIZE [4096]
CMDLINE [debug]
ASUS_I006D:/data/develop #
Use dd (or fastboot) to flash the new boot image, e.g:
dd if=../new_boot.img of=/dev/block/by-name/boot_b
Notes:
To define additional kernel parameter add them to the line using the blank as separator for the parameter - e.g.:
Code:
cmdline=loglevel=7 debug
The list of known kernel parameter for the ASUS Zenfone 8 can be found in the file
./kernel/asus/sm8350/Documentation/admin-guide/kernel-parameters.txt
in the source for the Android OS used (but most of the parameter described there are useless for the Android OS I guess ...)
The method described above can also be used to define additional kernel parameter for the kernel in the TWRP image. Note that you should never delete the kernel parameter twrpfastboot=1 in the TWRP boot image.
Unpacking and repacking the boot image can also be done on a PC running the Linux OS using the x86 version of magiskboot from the Magisk apk file.
To extract the magiskboot binary for 64 Bit Linux from the apk file use these commands:
Bash:
unzip -p Magisk-v26.1.apk lib/x86_64/libmagiskboot.so >magiskboot
chmod 755 magiskboot
The x86 binaries from the Magisk apk file are static linked binaries and should work on every Linux OS running on x86.
The Magisk Module cmdpatch (https://github.com/Magisk-Modules-Alt-Repo/cmdpatch) contains a script to add new kernel parameter
bnsmb said:
To define additional boot parameter add them to the line cmdline= in the file header and repack the boot image...
Click to expand...
Click to collapse
There's no particular need to unpack/pack the image.
The image added options to cmdline are right there in the header.
Just hexedit at offset 0x40 (for Android image versions 0, 1, 2) or offset 0x2c (for Android image versions 3, 4).
If your device uses AVB0 you may need to regenerate that.
Renate said:
There's no particular need to unpack/pack the image.
The image added options to cmdline are right there in the header.
Just hexedit at offset 0x40 (for Android image versions 0, 1, 2) or offset 0x2c (for Android image versions 3, 4).
If your device uses AVB0 you may need to regenerate that.
Click to expand...
Click to collapse
Thanks for the update - good to know that
You seem to know the Android kernel much better than I do.
My goal in playing with the kernel parameter was to find a way to get more messages from the kernel to find out why I can't boot the phone from a TWRP image via fastboot boot <twrpimage> when LineageOS 20.x is installed
But I was not successful ... do you know if this is possible?
regards
Bernd
bnsmb said:
My goal in playing with the kernel parameter was to find a way to get more messages from the kernel to find out why I can't boot the phone from a TWRP image via fastboot boot <twrpimage> when LineageOS 20.x is installed
Click to expand...
Click to collapse
There are cases where fastboot boot recimage does not work but fastboot flash recovery recimage and go to recovery does.
I've never chased this down all the way. Many parameters for cmdline are generated on the fly from abl.
I presume that there is some parameter specific to recovery that is not inserted when you boot from memory.
I haven't used TWRP in years, I just roll my own recovery with rooted ADB.
I don't need any screen stuff.
Also, you could use my imgutil.exe (in the sig)
Code:
C:\>imgutil /v boot
Header2: 1,660 (0000067c)
Kernel: 12,626,808 (00c0ab78) 00000800
Ramdisk: 1,224,504 (0012af38) 00c0b800
DTB: 68,134 (00010a26) 00d36800
Command: bootopt=64S3,32N2,64N2 buildvariant=user
C:\>imgutil /v boot /c"bootopt=64S3,32N2,64N2 buildvariant=user silly=always"
Header2: 1,660 (0000067c)
Kernel: 12,626,808 (00c0ab78) 00000800
Ramdisk: 1,224,504 (0012af38) 00c0b800
DTB: 68,134 (00010a26) 00d36800
Command: bootopt=64S3,32N2,64N2 buildvariant=user
Replaced cmdline
Wrote image
C:\>imgutil /v boot
Header2: 1,660 (0000067c)
Kernel: 12,626,808 (00c0ab78) 00000800
Ramdisk: 1,224,504 (0012af38) 00c0b800
DTB: 68,134 (00010a26) 00d36800
Command: bootopt=64S3,32N2,64N2 buildvariant=user silly=always

Categories

Resources