Chico de UNIX desde hace mucho tiempo aquí, pero relativamente nuevo en el mundo de Android. sigue leyendo
EPISODIO 1: Una nueva copia de seguridad (esperaba)
Recientemente compré un Asus MemoPAD (ME103K); Luego me convertí en root y tomé una dd
imagen de la system
partición de solo lectura en la tarjeta SD externa:
$ su
# dd if=/dev/block/platform/msm_sdcc.1/by-name/system \
of=/storage/MicroSD/system.img bs=1M
# ls -l /storage/MicroSD/system.img
-rw-r--r-- 1 root root 2147483648 Sep 27 13:15 system.img
El tamaño (exactamente 2GiB) era un poco sospechoso. ¿Podría ser debido a la partición FAT32 en la tarjeta SD?
No, no lo fue: tune2fs -l
reveló que, de hecho, se trataba de una imagen EXT4 válida, con un tamaño exacto de 2GiB, que pasó fsck -f
sin ningún error. Y fastboot
(desde la máquina Linux adjunta a la tableta) estuvo de acuerdo, después de un adb reboot bootloader
:
linuxbox# fastboot getvar all
(bootloader) version-bootloader: 3.03
(bootloader) version-hardware: rev_c
(bootloader) variant: LEOPARDCAT 16G
(bootloader) version-baseband: H00_0.16.F_0521
(bootloader) serialno: 0a3dXXXX
...
(bootloader) partition-type:system: ext4
(bootloader) partition-size:system: 0x0000000080000000
Ese tamaño, es de hecho 2GB:
linuxbox# python2 -c 'print 0x0000000080000000'
2147483648
Entonces, todo está bien: tengo una copia de seguridad de la imagen. Ahora a probar restaurarlo.
Intento volver a actualizar system.img a la tableta, para asegurarme de que puedo recuperarme de cualquier cosa, el tipo de copia de seguridad a prueba de balas que hacemos en el mundo de Unix ( por ejemplo, restaurar el contenido de una unidad a través dedd if=backup.image of=/dev/sdXXX
).
Todo lo relacionado con adb
y fastboot
funciona perfectamente, así que intento...
linux_box# fastboot devices
0a3dXXXX fastboot
linux_box# mount /dev/sdcard /mnt/sdcard
linux_box# cp /mnt/sdcard/system.img .
linux_box# fastboot flash system system.img
error: cannot load 'system.img'
Mmm. Descargo y construyo el android-tools-5.1.1
de mi distribución desde las fuentes, agregando información de depuración, y entro en el depurador para ver esta falla:
linuxbox# gdb --args fastboot flash system system.img
...
Interesante: aunque estoy en una máquina de 64 bits, aparentemente hay problemas que hacen que el tamaño del archivo sea "negativo" (en un mundo de 32 bits, el tamaño del archivo de mi imagen, 2^31, se considera negativo, para ser exactos, -2147483648
.
OK, bien, ¿cómo muestran archivos de imágenes grandes en Android?
Buscar en Google, buscar: resulta que usan esta make_ext4fs
herramienta, que crea imágenes flasheables. De hecho, es parte de lo que acabo de compilar, así que también podría usarlo:
linuxbox# mkdir /system
linuxbox# mount -o loop,ro system.img /system
linuxbox# ls -l /system
total 208
drwxr-xr-x 106 root root 8192 Sep 17 22:24 app
drwxr-xr-x 3 root 2000 8192 Sep 26 21:08 bin
-rw-r--r-- 1 root root 6847 Sep 12 16:59 build.prop
drwxr-xr-x 19 root root 4096 Sep 26 21:08 etc
drwxr-xr-x 2 root root 4096 Aug 11 22:27 fonts
drwxr-xr-x 4 root root 4096 Sep 12 16:56 framework
drwxr-xr-x 10 root root 16384 Sep 12 16:59 lib
drwxr-xr-x 2 root root 4096 Jan 1 1970 lost+found
drwxr-xr-x 3 root root 4096 Aug 11 22:18 media
drwxr-xr-x 59 root root 4096 Aug 11 22:29 priv-app
-rw-r--r-- 1 root root 126951 Aug 1 2008 recovery-from-boot.p
drwxr-xr-x 3 root root 4096 Aug 11 21:02 scripts
drwxr-xr-x 3 root root 4096 Aug 11 21:02 tts
drwxr-xr-x 11 root root 4096 Sep 26 21:08 usr
drwxr-xr-x 8 root 2000 4096 Aug 11 22:29 vendor
drwxr-xr-x 2 root 2000 4096 Sep 26 21:09 xbin
linuxbox# ../extras/source/extras/ext4_utils/make_ext4fs \
-l 2048M new_system.img /system
Creating filesystem with parameters:
Size: 2147483648
Block size: 4096
Blocks per group: 32768
Inodes per group: 8192
Inode size: 256
Journal blocks: 8192
Label:
Blocks: 524288
Block groups: 16
Reserved block group size: 127
Created filesystem with 2666/131072 inodes and 375014/524288 blocks
Genial, por lo que aparentemente puedo crear imágenes del sistema a partir de carpetas antiguas. El cielo será mi límite: podré agregar lo que quiera a esta imagen.
Vamos a quemarlo...
linuxbox# fastboot flash system new_system.img
erasing 'system'...
OKAY [ 0.064s]
sending 'system' (2088960 KB)...
^C
Esperé 1 hora antes de presionar Ctrl-C. Y tuve que apagar y encender la tableta, que se reinició en modo fastboot.
Esto no pinta bien.
¿Qué pasa si construyo una imagen más pequeña? Tal vez los 2 GB sean de alguna manera un problema, y esta partición no se usa a plena capacidad; tiene espacio libre:
linuxbox# ../extras/source/extras/ext4_utils/make_ext4fs \
-l 1536M new_system.img /system
linuxbox# ./fastboot flash system system.img
erasing 'system'...
OKAY [ 0.065s]
sending 'system' (1572864 KB)...
OKAY [ 51.039s]
writing 'system'...
OKAY [235.080s]
finished. total time: 286.183s
OK, esto parece muy prometedor (y solo tomó 5 minutos). Supongo que ahora puedo reiniciar y todo debería ser normal, ¿sí?
No :-)
No me importa un dispositivo bloqueado temporalmente, siempre que al final pueda controlarlo (las máquinas de las que no soy un maestro, son máquinas que no me importa operar ;-)
¿Alguna idea sobre lo que hice mal y qué puedo hacer para solucionarlo?
Gracias por adelantado.
PD Revisé la página de soporte de Asus para mi tableta: solo proporcionan las fuentes para el kernel y el archivo Over-the-air .zip. Eso, a su vez, contiene una copia de seguridad a nivel del sistema de archivos desde la raíz, es decir, la system
carpeta existe allí solo como una carpeta, no como una imagen, no como una system.img
que pueda flashear, por lo que realmente no me ayuda.
EPISODIO 2: El ataque de las botas personalizadas
En ausencia de cualquier tipo de recovery.img
Asus (¿por qué un fabricante se molestaría en publicar un fastboot-flashable recovery.img
? ¿Por qué de hecho...) y una ausencia similar en las imágenes de recuperación de los sitios CWM y TWRP... Me queda luchar contra todos solo.
Afortunadamente, el archivo de actualización por aire de Asus incluye en su interior...
linuxbox# unzip -l /opt/Asus/firmware/UL-K01E-WW-12.16.1.12-user.zip |\
grep boot.img$
7368704 2011-03-22 11:21 boot.img
...la imagen de arranque de mi tableta. Ahora tal vez, solo tal vez, pueda hacer algo con esto.
linuxbox$ mkdir rootfs
linuxbox$ cd rootfs
linuxbox$ abootimg -x /path/to/boot.img
linuxbox$ ls -l
bootimg.cfg
initrd.img
zImage
Ampliando el ramdisk...
linuxbox$ mkdir initrd
linuxbox$ cd initrd
linuxbox$ gzip -cd ../initrd.img | cpio -ivd
...
linuxbox$ vi default.prop
Me configuré default.prop
para ser root cuando se inicia el kernel:
ro.secure=0
ro.debuggable=1
ro.adb.secure=0
androidboot.selinux=disabled
También copié /system/bin/sh
( del archivo .zip de Asus por aire ) en /sbin/sh
. Hice lo mismo con busybox , una herramienta bastante útil.
Y volví a empaquetar boot.img...
busybox$ find . | cpio --create --format='newc' | gzip -9 > ../initrd.custom.gz
busybox$ cd ..
busybox$ abootimg --create ../new_boot_busybox.img \
-f bootimg.cfg -k zImage -r initrd.custom.gz
abootimg
en realidad falló la primera vez que ejecuté esto, ya bootimg.cfg
que tuvo que actualizarse; el bootsize
parámetro tuvo que cambiarse, ya que el paquete es más grande ahora. abootimg
informa lo que necesita, por lo que es bastante fácil.
Y ahora, inicio mi imagen personalizada...
linuxbox# fastboot boot new_boot_busybox.img
...y sea testigo de lo siguiente...
linuxbox# adb logcat
- exec '/system/bin/sh' failed: Permission denied (13) -
linuxbox# adb shell
- exec '/system/bin/sh' failed: Permission denied (13) -
Hmm... ¿Tal vez adbd no se ejecuta como root?
linuxbox# adb root
restarting adbd as root
linuxbox# adb shell
- exec '/system/bin/sh' failed: Permission denied (13) -
Bien... He editado adbd y parcheado /system/bin/sh para que sea /sbin/sh (copié /system/bin/sh de la imagen OTA al rootfs del initrd): Reboot, fastboot...
linuxbox# adb shell
- exec '/sbin/sh' failed: Permission denied (13) -
Maldito. ¿Esta cosa es capaz de hacer algo?
linuxbox# adb pull /proc/partitions
15 KB/s (1272 bytes in 0.079s)
Es... a ver:
linuxbox# adb pull /proc/mounts
16 KB/s (1358 bytes in 0.079s)
linuxbox# grep system mounts
/dev/block/platform/msm_sdcc.1/by-name/system /system ext4 rw,seclabel,relatime,data=ordered 0 0
OK, entonces /system está montado. ¿Puedo ver lo que hay dentro?
linuxbox# adb pull /system
remote object '/system' does not exist
Qué... Tal vez pueda verificar qué contiene /proc/kmsg (lo que generaría "dmesg")
linuxbox# adb pull /proc/kmsg
failed to copy '/proc/kmsg' to './kmsg': Operation not permitted
Nah, necesito ser root para hacer eso.
linuxbox# adb push /sbin/sh /system/bin/sh
failed to copy '/sbin/sh' to '/system/bin/sh': Permission denied
Y eso también.
Esto se está convirtiendo en un gran rompecabezas...
Episodio 3: El regreso de la concha.
Si alguna vez tenía alguna posibilidad de resolver esto, primero tenía que averiguar por qué el caparazón no funcionaba. adbd
estaba respondiendo, por lo que se inició en el lado de la tableta, pero no pudo ejecutar el shell, incluso cuando lo parcheé para invocar un archivo ( /sbin/sh
) que yo mismo coloqué en la imagen de arranque, estando 100% seguro de que tenía los permisos adecuados y era accesible desde la shell
cuenta (id=2000) que adbd
utiliza.
Lo que dejó solo una explicación: las "jaulas" de SELinux.
Así que verifiqué cómo adbd
se inició desde mi imagen de arranque init.rc
:
# adbd is controlled via property triggers in init.<platform>.usb.rc
service adbd /sbin/adbd --root_seclabel=u:r:su:s0
class core
socket adbd stream 660 system system
disabled
seclabel u:r:adbd:s0
... y probé un cambio obvio:
service adbd /sbin/adbd
class core
socket adbd stream 660 system system
Volví a empacar y, para mi gran satisfacción, vi...
linuxbox# adb shell
$
Finalmente obtuve acceso a la tableta, desde "adentro".
Al revisar el /system montado, quedó claro que el proceso de flasheo, aunque fastboot flash system ...
se informó que todo estaba bien, había fallado espectacularmente . Fue una maravilla que la partición estuviera montada en primer lugar.
Eso explicaba por qué la tableta no arrancaba y me dio la idea final que resolvió el problema.
Necesitaba iniciar la tableta para que usara mi copia prístina de la partición / system, pero en este punto, aunque tenía acceso de shell, no era root ( los cambios que hice default.prop
aparentemente son ignorados por el kernel de Asus) Tendré que volver a compilarlo pronto... ) así que no pude montar la tarjeta SD externa y dd
sobre mi buena copia.
Pero tenía mi propia imagen de arranque, lo que significaba que podía editar el /fstab.qcom
interior y hacer esto:
Línea original que le decía a la tableta cómo montar /sistema
/dev/block/platform/msm_sdcc.1/by-name/system /system ext4 ro,barrier=1 wait
Mi edición
/dev/block/mmcblk1p2 /system ext4 rw,barrier=1 wait
... y de vuelta en mi caja de Linux, dd
edité la copia de seguridad impecable de la partición del sistema de la tableta en la segunda partición de mi tarjeta SD externa, que creé gparted
para que tuviera exactamente 2 GB.
Eso lo hizo: la tableta arrancó desde mi tarjeta SD externa.
EDITAR : El viaje continuó: eventualmente parcheé y compilé mi propio kernel y me convertí en root .
fastboot boot ...
) y la /system
partición está en la tarjeta SD, modificable a lo que yo quiera. Algo así como arrancar una PC desde una memoria USB :-)Parece que ya encontró algún tipo de solución a su problema (hay mucho texto para leer en esta página), pero parece que esto probablemente podría haberse resuelto de manera mucho más simple.
linuxbox# fastboot getvar all
(bootloader) version-bootloader: 3.03
(bootloader) version-hardware: rev_c
(bootloader) variant: LEOPARDCAT 16G
(bootloader) version-baseband: H00_0.16.F_0521
(bootloader) serialno: 0a3dXXXX
...
(bootloader) partition-type:system: ext4
(bootloader) partition-size:system: 0x0000000080000000
Entre estas variables, ¿su tableta devolvió una max-download-size
variable? Si es así, eso podría haber proporcionado una advertencia, directamente, de que el proceso de actualización podría tener algunos problemas con una imagen tan grande. El código fastboot actual está hecho para solucionar un problema max-download-size
que es demasiado pequeño, pero he experimentado el mismo error incluso cuando la imagen es más pequeña de lo que el dispositivo dice que puede manejar, por lo que en realidad el punto es un poco discutible, supongo.
linux_box# fastboot flash system system.img
error: cannot load 'system.img'
Entonces, de todos modos, parece que aquí, por alguna razón, no puede flashear. Si usted y yo tenemos razón, y se trata del tamaño (su tableta solo tiene 1 GB de RAM, y supuestamente la mayoría de los dispositivos intentan leer la imagen completa en la RAM antes de parpadear ), aquí es donde creo que el mero ajuste de agregar la -S
opción a fastboot podría haber arreglado su flash como lo ha hecho para mí:
fastboot -S 512M flash system system.img
En su lugar, sin embargo, parece que intentó forzar su imagen de 2 GB en un tamaño que (1) podría no ser posible para que se rellene y (2) no es el tamaño que se supone que debe ser la partición del sistema de su dispositivo.
Con respecto al punto #1, en mi experiencia, no contaría con las frágiles herramientas de compilación de Android para quejarse si les pide que hagan algo en lo que fallarán, y es posible que lo hayan hecho aquí.
Con respecto al punto n. ° 2, no creo que no puedas hacer eso; se requerirían pasos adicionales para usar un tamaño de partición de sistema diferente.
Suponiendo que su tableta espera archivos de imagen dispersos, creo que el comando que quería probar en lugar de make_ext4fs -l 1536M new_system.img /system
era make_ext4fs -l 2048M -s new_system.img /system
. El comando ajustado crearía una imagen que se infla al tamaño correcto, pero se almacena temporalmente sin exceso de grasa como grandes bolsillos de datos vacíos: un " archivo de imagen dispersa " (consulte la página a la que me vinculé anteriormente para obtener más información sobre ellos; No tengo suficiente reputación en este sitio para repetir el enlace).
Este antiguo archivo Léame que alguien escribió para una colección de herramientas debería ayudar a comprender cómo funciona el proceso.
Salud.
max-download-
nada en la salida de getvar
. (2) Tendré en cuenta la -S
opción en mis flashes futuros; tal como está, una vez que inicié, me convertí en root (recompilando mi kernel) y dd
-ed sobre la partición del sistema anterior, por lo que si flashear con -S funcionaría. tengo que esperar mis próximas pruebas (3) Lo intenté con imágenes dispersas, obtuve el mismo resultado (es decir fastboot
, informé que el flasheo estaba bien, pero la partición del sistema estaba en mal estado).all
se puede pasar a getvar, eso es útil). (2) Oh, está bien. Si funciona, háganoslo saber. (3) ¡Vaya! No me di cuenta de eso. Es mucho texto, lo siento. ¿Se mencionó eso en sus publicaciones? (¿Era como el comando make_ext4fs que sugerí, con -s
una longitud completa de 2 GiB especificada?) Tal vez la tableta no maneja archivos dispersos.-s
a make_ext4fs - fastboot informó 'OK' para grabar, pero /system estaba en mal estado. Mi teoría es que, como dijiste, cualquier cosa más grande que la memoria de la tableta (1 GB) no funcionaría, y necesitaba la -S
opción en fastboot para funcionar correctamente (lo que explica el estado medio roto: la partición se montó porque la primera parte de la imagen cabía en la memoria y en realidad se quemó, lo que permitió montarla, pero los archivos dentro de ella se... corrompieron al azar, dependiendo de si sus sectores se quemaron o no).Con mi Moto GI creé una copia de seguridad usando dd como lo hiciste. Necesitaba restaurar la partición de mi sistema el otro día, así que inicié TWRP (no lo actualicé, solo inicié la imagen en la RAM). Luego usé adb para conectarme mientras se ejecutaba TWRP y simplemente presioné la imagen que hice con dd en mi tarjeta SD y luego usé dd para escribir la imagen en la partición del sistema.
Mira los videos que he hecho sobre esto aquí: https://youtu.be/BHCamV-sHx0?list=PLcUid3OP_4OVI1Rtuwxk1RjABh1PxXXQq
recovery.img
de Asus, y tampoco existe CWM o TWRP (para un ME103K).
Señor del Fuego
ttsiodras
fastboot
todavía está operativo (responde bien a las solicitudes) y, por lo tanto, puedo grabar cualquier imagen de recuperación, (a) busqué y no encontré ninguna imagen de recuperación CWM o TWRP para ME103K - Supongo que no hay uno "genérico" al que te refieres, ¿no? (b) Apagar, presionar el botón de encendido + bajar el volumen no muestra la imagen de recuperación; todavía llego al estado de arranque rápido. Mo idea de por qué. De hecho, nunca he visto el proceso de recuperación (algo curioso por verlo)...Señor del Fuego
fastboot boot <FILE>.img
), luego flashear todo el archivo ZIP de stock. Alternativamente, vea si existen (en la web) los archivos ROM de stock que se pueden actualizar usando fastboot.ttsiodras
unzip -l UL-K01E-WW-12.16.1.12-user.zip | grep recovery
muestra solo un par de scripts de shell; echaré un vistazo, pero definitivamente no hayrecovery.img
allí). Buscar en Google tampoco ayudó: no hay imágenes de recuperación de esta tableta en ninguna parte... ¿Supongo que tendré que esperar a que algún alma caritativa llegue add
su partición de recuperación y las comparta?