0

I already have Magisk installed by patching boot_b — the current boot partition. Therefore I have root privilege and can access it through the su command in Termux. The issue is that when I update LineageOS through OTA, it also updates the boot image, so I lose Magisk every time I update. And so, I need a computer to install it back every time I update (that is, every week or so).

I'm trying to get away with installing Magisk from the phone right after the update while I'm still on the rooted partition.

I've successfully extracted the updated boot_a partition using cp /dev/block/by-name/boot_a /data/data/com.termux/files/home/storage/documents/boot_a.img, patched it though Magisk, and now I'm trying to flash the patched image back with dd if=/data/data/com.termux/files/home/storage/downloads/magisk_patched-25200_FyF2V.img of=/dev/block/by-name/boot_a

But it says that operation is not permitted and refuses to do the thing:

dd: /dev/block/by-name/boot_a: write error: Operation not permitted
1+0 records in
0+0 records out
0 bytes (0 B) copied, 0.002583 s, 0 B/s

I find it strange since there are posts (1, 2) where people managed to do the same.

Again, I'm running the command in a root shell given by su. And, as you can see, the files' permissions are set to rw for the root owner:

# ls -l /dev/block/by-name/boot_a /dev/block/mmcblk0p38                                                                                                                         
lrwxrwxrwx 1 root root       21 1970-07-16 15:34 /dev/block/by-name/boot_a -> /dev/block/mmcblk0p38
brw------- 1 root root 259,   6 2022-08-31 22:02 /dev/block/mmcblk0p38
# whoami
root

I've also set SELinux to permissive just in case, but it didn't help either:

# getenforce
Permissive

I've also found a great story in two questions (1, 2) from someone with a somewhat similar problem, and they determined it was the lack of some linux capabilities that stopped them from chrooting. So, I've also tried to find if I lack some "capability" to dd, and it seems I indeed don't have any capabilities on the toybox binary, which provides dd. Although, I have all 38 capabilities for the current process (the shell):

# ls -l `which dd`
lrwxrwxrwx 1 root root 6 1970-07-16 15:34 /system/bin/dd -> toybox
# getcap /system/bin/dd
# getcap /system/bin/toybox        
# getcap /dev/block/by-name/boot_a                                                                                                                                              
# getcap /dev/block/mmcblk0p38
# cat /proc/self/status | grep Cap                                                                                                                                              
CapInh: 0000000000000000
CapPrm: 0000003fffffffff
CapEff: 0000003fffffffff
CapBnd: 0000003fffffffff
CapAmb: 0000000000000000
[ThisOneRan@PC]$ capsh --decode=0000003fffffffff
0x0000003fffffffff=cap_chown,cap_dac_override,cap_dac_read_search,cap_fowner,cap_fsetid,cap_kill,cap_setgid,cap_setuid,cap_setpcap,cap_linux_immutable,cap_net_bind_service,cap_net_broadcast,cap_net_admin,cap_net_raw,cap_ipc_lock,cap_ipc_owner,cap_sys_module,cap_sys_rawio,cap_sys_chroot,cap_sys_ptrace,cap_sys_pacct,cap_sys_admin,cap_sys_boot,cap_sys_nice,cap_sys_resource,cap_sys_time,cap_sys_tty_config,cap_mknod,cap_lease,cap_audit_write,cap_audit_control,cap_setfcap,cap_mac_override,cap_mac_admin,cap_syslog,cap_wake_alarm,cap_block_suspend,cap_audit_read
# cat /proc/sys/kernel/cap_last_cap                                                                                                                                           
37

So, I've tried to set cap_dac_override for the /system/bin/toybox binary, but couldn't — it is read-only:

# setcap cap_dac_override+ep /system/bin/toybox                                                                                                                                 
Failed to set capabilities on file `/system/bin/toybox' (Read-only file system)

Form running mount | grep system it turns out that not the system itself is mounted, but... Magisk's system_root bloack device to eash individual binary and stuff. So, I have remounted toybox as rw:

# mount | grep toybox                                                                                                                                                           
/dev/DBScy/.magisk/block/system_root on /system/bin/toybox type ext4 (ro,seclabel,relatime)
# mount -o remount,rw /dev/DBScy/.magisk/block/system_root /system/bin/toybox                                                                                                   
# mount | grep toybox                                                                                                                                                           
/dev/DBScy/.magisk/block/system_root on /system/bin/toybox type ext4 (rw,seclabel,relatime)

This allowed me to setcap all capabilities:

# setcap all+ep /system/bin/toybox
# getcap /system/bin/toybox                                                                                                                                                     
/system/bin/toybox =ep

But even with this, I'm still not permitted to flash the boot image:

# dd if=/data/data/com.termux/files/home/storage/downloads/magisk_patched-25200_FyF2V.img of=/dev/block/by-name/boot_a                                                          
dd: /dev/block/by-name/boot_a: write error: Operation not permitted
1+0 records in
0+0 records out
0 bytes (0 B) copied, 0.001446 s, 0 B/s
# dd if=/data/data/com.termux/files/home/storage/downloads/magisk_patched-25200_FyF2V.img of=/dev/block/mmcblk0p38                                                              
dd: /dev/block/mmcblk0p38: write error: Operation not permitted
1+0 records in
0+0 records out
0 bytes (0 B) copied, 0.000779 s, 0 B/s

At this point I've no idea what else to try, or where my obvios mistake could be, so please help me figure it out. Thanks in advance!

1 Answer 1

0

Strange, but after a reboot to the same prefix, it allowed me to flash it without any "capabilities" and with enforcing SELinux. And everything worked perfectly as intended. I've no idea what caused it to not work on the first try, maybe I had to restart the shell?

Anyway, to boot into the same prefix on the next re/boot, you should set the active boot slot using bootctl set-active-boot-slot `bootctl get-current-slot`

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .