0 votos

¿Cómo flashear la partición de arranque desde el teléfono mismo?

Ya tengo instalado Magisk parcheando boot_b — la partición de arranque actual. Por lo tanto, tengo privilegios de root y puedo acceder a través del comando su en Termux. El problema es que cuando actualizo LineageOS a través de OTA, también actualiza la imagen de arranque, por lo que pierdo Magisk cada vez que actualizo. Y así, necesito una computadora para reinstalarlo cada vez que actualizo (es decir, cada semana aproximadamente).

Estoy tratando de instalar Magisk desde el teléfono justo después de la actualización mientras sigo en la partición con root.

He extraído con éxito la partición actualizada boot_a usando cp /dev/block/by-name/boot_a /data/data/com.termux/files/home/storage/documents/boot_a.img, lo he parcheado a través de Magisk, y ahora estoy tratando de flashear la imagen parcheada de vuelta con dd if=/data/data/com.termux/files/home/storage/downloads/magisk_patched-25200_FyF2V.img of=/dev/block/by-name/boot_a

Pero dice que la operación no está permitida y se niega a hacerlo:

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

Me parece extraño ya que hay publicaciones (1, 2) donde personas lograron hacer lo mismo.

Nuevamente, estoy ejecutando el comando en un shell de root dado por su. Y, como puedes ver, los permisos de los archivos están establecidos en rw para el propietario root:

# 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

También he establecido SELinux en permissive por si acaso, pero tampoco ayudó:

# getenforce
Permissive

También encontré una gran historia en dos preguntas (1, 2) de alguien con un problema algo similar, y determinaron que era la falta de algunas capacidades de Linux lo que les impidió acceder a chroot. Por lo tanto, también he intentado ver si me falta alguna "capacidad" para dd, y parece que de hecho no tengo ningún permiso en el binario toybox, que proporciona dd. Aunque tengo las 38 capacidades para el proceso actual (el 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

Entonces, intenté establecer cap_dac_override para el binario /system/bin/toybox, pero no pude — es de solo lectura:

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

Al ejecutar mount | grep system resulta que no se monta el sistema en sí, sino... el dispositivo bloack system_root de Magisk para cada binario individual y cosas. Por lo tanto, he vuelto a montar toybox como 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)

Esto me permitió setcap todas las capacidades:

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

Pero aún así, no se me permite flashear la imagen de arranque:

# 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) copiados, 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) copiados, 0,000779 s, 0 B/s

En este punto, no tengo idea de qué más intentar, o dónde podría estar mi error obvio, así que por favor ayúdame a descubrirlo. ¡Gracias de antemano!

0voto

RN Kushwaha Puntos 101

Extraño, pero después de reiniciar en el mismo prefijo, me permitió flashearlo sin ninguna "capacidad" y con SELinux obligatorio. Y todo funcionó perfectamente según lo previsto. No tengo idea de qué causó que no funcionara en el primer intento, tal vez tuve que reiniciar la terminal?

De todos modos, para arrancar en el mismo prefijo en el próximo reinicio, debes establecer la ranura de arranque activa usando bootctl set-active-boot-slot `bootctl get-current-slot`

PreguntAndroid.com

PreguntAndroid es una comunidad de usuarios de Android en la que puedes resolver tus problemas y dudas.
Puedes consultar las preguntas de otros usuarios, hacer tus propias preguntas o resolver las de los demás.

Powered by:

X