If we assign the execution output directly it will fail (tested on Android 11):
pdx201:/ # INSTALLER=/data/adb/magisk_install /data/adb/magisk_install/flash_script.sh
/data/adb/magisk_install/flash_script.sh[31]: typeset: -o: is not an identifier
Because:
local cmds=$($bb sh -o standalone -c "
for arg in \$(tr '\0' '\n' < /proc/$$/cmdline); do
if [ -z \"\$cmds\" ]; then
# Skip the first argument as we want to change the interpreter
cmds=\"sh -o standalone\"
else
cmds=\"\$cmds '\$arg'\"
fi
done
echo \$cmds")
/system/bin/sh: typeset: -o: is not an identifier
Signed-off-by: Pablo Mendez Hernandez <pablomh@gmail.com>
Previously, Magisk uses persist or cache for storing modules' custom
sepolicy rules. In this commit, we significantly broaden its
compatibility and also prevent mounting errors.
The persist partition is non-standard and also critical for Snapdragon
devices, so we prefer not to use it by default.
We will go through the following logic to find the best suitable
non-volatile, writable location to store and load sepolicy.rule files:
Unencrypted data -> FBE data unencrypted dir -> cache -> metadata -> persist
This should cover almost all possible cases: very old devices have
cache partitions; newer devices will use FBE; latest devices will use
metadata FBE (which guarantees a metadata parition); and finally,
all Snapdragon devices have the persist partition (as a last resort).
Fix#3179
- Do not attempt to patch DTB anywhere outside of boot images as they
are no longer essential. This makes Magisk installation to only modify
strictly boot/recovery partitions again.
- The only required patch for DTB is to strip verity out of partitions
- /vendor is used only on some older devices for recovery AVBv1 signing so is not critical if fails
- this fixes installation in Lineage Recovery on some older devices where /vendor is actually by-name partitions like oem, cust (or even cache), which likely also don't require the AVBv1 signing
- bugged TWRPs were filling persist with recovery logs, so clean those as a potential workaround
- abort module install if sepolicy.rule fails to copy, since 99% of the time the module wouldn't include it if it could function without it
Closes#2461
- try /dev/block first with full depth to catch all platform/soc variations to the by-name directory, and the new dynamic partition /dev/block/mapper
- next try uevent for block devices as before
- lastly try /dev with maxdepth 1 (immediate directory) to find /dev/bootimg, /dev/recovery, etc. while avoiding /dev/log/kernel
- move bootimg higher in the list than boot so /dev/bootimg gets found first and avoids /dev/BOOT
- recovery_a/_b now also exists
- minor touch-ups for readability and consistency
Fixes#2720
- this is needed for installations on Lineage 17.1 Recovery (AOSP Q) for logical partition devices, which uses /dev/block/mapper to stage the partitions
Thanks LuK1337 & erfanoabdi @ Lineage
- /proc/$$/cmdline is \0 terminated argument strings except for the last argument which has no terminus, so the last argument was being dropped by `while read` which requires input to be \n terminated
- switch to a for loop, which will use the \n delimiter but also read the last argument; all arguments are still protected by quoting
- clean up potentially breaking recovery env since $OLD_PATH no longer exists
* Lineage Recovery 17.1, like AOSP Q recovery, has '/' as a shared
mount point, causing `mount --move` to fail.
If it fails, directly mount system to /system_root via
/dev/block/ symlinks, like AnyKernel and OpenGapps
Co-authored-by: John Wu <topjohnwu@gmail.com>
- adjust mount scripts to support SOS, APP and CAC Tegra partition naming (vendor is still vendor, oddly)
- -Xnodex2oat is removed on Android 10 in AOSP (despite it still erroneously showing in dalvikvm --help); older devices will still run safely without it
- Android 10 dynamically linked binaries need APEX mounts and variables so add this to recovery_actions/cleanup (thanks @Zackptg5)
- clean up known systemless root leftovers because we're helpful
- Update backup format as we might be patching multiple partitions
- Update uninstaller to remove files in persist (sepolicy.rule)
- Better handling for dtb/dtbo partition patching
The new module installer script completely changes the way how module
installer zips are structured. More info will come later in docs.
The new installer script also supports installing sepolicy.rule to
persist partitions in order to make the module work on the next boot.
- change to $TMPDIR in addon.d.sh since recovery addon.d-v1 backup + restore leaves you in /tmp/addon.d which the restore then deletes, which would break $BOOTSIGNER execution with the following:
libc: Fatal signal 11 (SIGSEGV), code 1 (SEGV_MAPERR), fault addr 0x0 in tid 1078 (main), pid 1078 (main)
Segmentation fault
- also move $BOOTSIGNER execution to after `cd $MAGISKBIN` to ensure it's in a working directory in all cases
- addon.d.sh data mount wasn't doing anything since /data has to already be mounted for the script to be running, so move it into /system/addon.d/99-magisk.sh stub script where it might be useful on recoveries that don't mount /data initially
Fixes#2013
- increase SignBoot bootimg header version maximum from 4 to 8 (upstream AOSP is already at 3) and make a variable for future ease
- hdr read size of 1024 bytes was too small as hdr_v1 and hdr_v2 have increased the used header page areas to 1632 and 1648 bytes, respectively, so raise this to the minimum page size of 2048 and also make a variable for future ease
- do not return "not signed" for all caught exceptions, show StackTrace for future debugging then still return false for script purposes
- correct "test keys" boot image signing strings (scripts and app) to "verity keys"
- remove redundant addon.d.sh script bits that were covered elsewhere ($TMPDIR in util_functions.sh, find_dtbo_image in patch_dtbo_image)
- refactor addon.d.sh and flash_script.sh for simplicity and readability, and put common flashing script in util_functions.sh (as patch_boot_image), which should greatly help avoid them getting out of sync going forward and fixes compressing ramdisk support and post-patch cleanup for addon.d
- add check_data to addon.d.sh since moving stock_boot* and stock_dtbo* backups depend on it and so weren't occuring with addon.d
- fix find_manager_apk with working fallback for recovery addon.d execution (where `magisk --sqlite` will not work for hidden Manager), Manager DynAPK hiding, and print a useful log warning if an APK can't be found
The way how logical partition, or "Logical Resizable Android Partitions"
as they say in AOSP source code, is setup makes it impossible to early
mount the partitions from the shared super partition with just
a few lines of code; in fact, AOSP has a whole "fs_mgr" folder which
consist of multiple complex libraries, with 15K lines of code just
to deal with the device mapper shenanigans.
In order to keep the already overly complicated MagiskInit more
managable, I chose NOT to go the route of including fs_mgr directly
into MagiskInit. Luckily, starting from Android Q, Google decided to
split init startup into 3 stages, with the first stage doing _only_
early mount. This is great news, because we can simply let the stock
init do its own thing for us, and we intercept the bootup sequence.
So the workflow can be visualized roughly below:
Magisk First Stage --> First Stage Mount --> Magisk Second Stage --+
(MagiskInit) (Original Init) (MagiskInit) +
+
+
...Rest of the boot... <-- Second Stage <-- Selinux Setup <--+
(__________________ Original Init ____________________)
The catch here is that after doing all the first stage mounting, /init
will pivot /system as root directory (/), leaving us impossible to
regain control after we hand it over. So the solution here is to patch
fstab in /first_stage_ramdisk on-the-fly to redirect /system to
/system_root, making the original init do all the hard work for
us and mount required early mount partitions, but skips the step of
switching root directory. It will also conveniently hand over execution
back to MagiskInit, which we will reuse the routine for patching
root directory in normal system-as-root situations.
Some devices (mainly new Samsung phones we're talking here...) using
A only system-as-root refuse to load ramdisk when booted with boot
no matter what we do. With many A only system-as-root devices, even
though their boot image is kernel only, we can still be able to add
a ramdisk section into the image and force the kernel to use it as
rootfs. However the bootloader on devices like the S10 simply does
not load anything within boot image into memory other than the kernel.
This gives as the only option is to install Magisk on the recovery
partition. This commits adds proper support for these kind of scenarios.
