Intentando flashear un system.img que tomé con dd - fallando

16

Hombre 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 ddimagen de la systempartició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 que esto se debió a la partición FAT32 en la tarjeta SD?

No, no se tune2fs -lreveló que se trataba de una imagen EXT4 válida, exactamente del tamaño de 2GiB, que pasó fsck -fsin ningún error. Y fastboot(desde la máquina Linux conectada a la tableta) coincidió, 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 para probar restaurarlo.

Intento actualizar el sistema .img de nuevo 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 Unix ( por ejemplo, restaurar el contenido de una unidad a través dedd if=backup.image of=/dev/sdXXX ).

Todo lo relacionado adby fastbootfunciona 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'

Hmm Descargo y construyo android-tools-5.1.1mi distribución desde las fuentes, agregando información de depuración, y paso al depurador para ver este error:

linuxbox# gdb --args fastboot flash system system.img
...

¡Falla debido al tamaño negativo!

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.

Bien, bien, ¿cómo muestran archivos de imágenes grandes en Android?

Buscar en Google, buscar: resulta que usan esta make_ext4fsherramienta, que crea imágenes flasheables. De hecho, es parte de lo que acabo de compilar, por lo que 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 construir imágenes del sistema a partir de carpetas antiguas simples. 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 tuvo 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 2GB son un problema, y ​​esta partición no se utiliza 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

Bien, esto parece muy prometedor (y solo tomó 5 minutos). Supongo que ahora puedo reiniciar y todo debería ser normal, ¿sí?

No :-)

ingrese la descripción de la imagen aquí

No me importa un dispositivo de ladrillo temporalmente, siempre y cuando no llegue a controlarlo en el extremo (máquinas que no soy un maestro de, son máquinas que no me interesa para operar ;-)

¿Alguna idea sobre lo que hice mal y qué puedo hacer para solucionar esto?

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 .zip por aire. Eso a su vez contiene una copia de seguridad a nivel del sistema de archivos desde la raíz, es decir, la systemcarpeta existe allí solo como una carpeta, no una imagen, no una system.imgque pueda flashear, por lo que eso realmente no me ayuda.

EPISODIO 2: Ataque de las botas personalizadas

En ausencia de cualquier tipo de recovery.imgAsus (¿por qué un fabricante se molestaría en publicar un flash de arranque rápido flasheable recovery.img? solo.

Afortunadamente, el archivo de actualización inalámbrica de Asus incluye dentro ...

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, puedo 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

Expandiendo el ramdisk ...

linuxbox$ mkdir initrd
linuxbox$ cd initrd
linuxbox$ gzip -cd ../initrd.img | cpio -ivd
...
linuxbox$ vi default.prop

Configuré default.propser root cuando arranca el kernel:

ro.secure=0
ro.debuggable=1
ro.adb.secure=0
androidboot.selinux=disabled

También copié /system/bin/sh( desde el archivo .zip de Asus por aire ) en /sbin/sh. Hice lo mismo con busybox , una herramienta bastante útil.

Y volvió a empacar el 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

abootimgen realidad falló la primera vez que ejecuté esto, ya que bootimg.cfgtenía que actualizarse; el bootsizeparámetro tenía que cambiarse, ya que el paquete ahora es más grande. abootimginforma lo que necesita, por lo que es bastante fácil.

Y ahora, arranco mi imagen personalizada ...

linuxbox# fastboot boot new_boot_busybox.img

... y ser 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 ... ¿Quizás 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 ... heededit adbd, y parche / system / bin / sh para ser / sbin / sh (copié / system / bin / sh de la imagen OTA a los rootfs del initrd): reinicio, arranque rápido ...

linuxbox# adb shell
- exec '/sbin/sh' failed: Permission denied (13) -

Maldito. ¿Es esta cosa capaz de hacer algo?

linuxbox# adb pull /proc/partitions
15 KB/s (1272 bytes in 0.079s)

Es ... veamos:

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 comprobar qué contiene / proc / kmsg (qué "dmesg" generaría)

linuxbox# adb pull /proc/kmsg
failed to copy '/proc/kmsg' to './kmsg': Operation not permitted

No, 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 está resultando ser todo un rompecabezas ...

ttsiodras
fuente
2
Lo único bueno que no hizo aquí (y debería haber hecho) es flashear una recuperación personalizada y luego tomar una copia de seguridad nandroid de las particiones. Ese es uno de los métodos a prueba de balas para recuperar dispositivos de un estado tan bloqueado. Ese Over-the-air.zip (OTA zip) es un zip recuperable flasheable, es decir, que se actualiza cuando se inicia en Recovery y sigue un formato de empaque diferente pero logra el mismo objetivo. En pocas palabras, flashee una recuperación personalizada (o inicie en stock), actualice la ROM de stock y luego experimente todo lo que desee.
Señor del fuego
1
@Firelord: Esa es la cuestión, aunque fastboottodaví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, ¿existe? (b) Apagar, presionar el botón de encendido + bajar el volumen no muestra la imagen de recuperación; todavía llego al estado de inicio rápido. Mo idea por qué. De hecho, nunca he visto el proceso de recuperación (algo curioso de verlo) ...
ttsiodras
1
Pruebe otras combinaciones de botones como Power + Vol Up + Vol Down para iniciar en modo de recuperación. Si tiene acceso a stock Recovery ZIP, puede haber un archivo de imagen de stock Recovery en algún lugar que puede flashear desde fastboot o iniciar directamente en él ( fastboot boot <FILE>.img), luego flashear todo el archivo ZIP de stock. Alternativamente, vea si existe (en la web) los archivos ROM de stock que pueden actualizarse mediante fastboot.
Señor del Fuego
1
@Firelord: No, Asus no proporciona un archivo recovery.zip. Desde el archivo OTA, no hay nada .img-y ( unzip -l UL-K01E-WW-12.16.1.12-user.zip | grep recoverymuestra solo un par de scripts de shell; lo echaré un vistazo, pero definitivamente no recovery.imghay ninguno ). Buscar en Google tampoco ayudó: no hay imágenes de recuperación de esta tableta en ningún lado ... Supongo que tendré que esperar a que un alma amable llegue a ddsu partición de recuperación y comparta.
ttsiodras

Respuestas:

7

Episodio 3: El retorno de la concha.

Si alguna vez tuve alguna posibilidad de resolver esto, primero tenía que descubrir por qué el shell no funcionaba. adbdestaba 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 fue accesible desde la cuenta shell(id = 2000) que adbdusa.

Lo que dejó solo una explicación: las "jaulas" de SELinux.

Así que verifiqué cómo adbdse inició desde la imagen de mi 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

... e intenté 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 comprobar el sistema / montado, quedó claro que el proceso de flasheo, aunque se fastboot flash system ...informó que todo estaba bien, había fallado espectacularmente . Era sorprendente que la partición se montara en primer lugar.

Eso explicaba por qué la tableta no se iniciaba y me dio la idea final que resolvió el problema.

Necesitaba arrancar la tableta para que utilizara mi copia prístina de la partición / system, pero en este punto, a pesar de que tenía acceso a shell, no era root ( los cambios que hice default.propaparentemente son ignorados por el núcleo de Asus) Tendré que volver a compilarlo pronto ... ) para no poder montar la tarjeta sd externa y ddsobre mi buena copia.

Pero tenía mi propia imagen de arranque, lo que significaba que podía editar el /fstab.qcominterior y hacer esto:

Línea original que le dijo 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, ddintroduje la copia de seguridad inmaculada de la partición del sistema de la tableta en la segunda partición de mi tarjeta SD externa, que creé gpartedpara tener exactamente 2 GB.

Eso lo hizo: la tableta arrancó desde mi tarjeta SD externa.

EDITAR : El viaje continuó: eventualmente parcheé y compilé mi propio núcleo y me convertí en root .

ttsiodras
fuente
2
Juro por el Episodio 4, habría ofrecido una recompensa si esta respuesta no fuera publicada, por diversión de todos estos episodios. Es bueno ver que resolvió su problema por su cuenta. : D
Señor del Fuego
2
@ Señor del Fuego: Gracias, amigo. En el proceso, creo que hice algo bastante bueno: inicié mi tableta sin tocar su interior ... la imagen de inicio proviene del exterior (sobre fastboot boot ...) y la /systempartición está en la tarjeta SD, modificable a lo que quiera. Algo así como arrancar una PC desde una memoria USB :-)
ttsiodras
4

Parece que ya ha encontrado 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-sizevariable? Si es así, eso podría haber proporcionado una advertencia directa, de que el proceso de flasheo podría tener algunos problemas con una imagen tan grande. El código actual de arranque rápido está hecho para funcionar en un entorno max-download-sizedemasiado pequeño, pero he experimentado su 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 discutible, supongo.

linux_box# fastboot flash system system.img  
error: cannot load 'system.img'

Entonces, de todos modos, parece aquí, que por cualquier razón, no puedes 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 flashear ), aquí es donde creo que el simple ajuste de agregar la -Sopción fastboot podría haber reparado tu flash como lo ha hecho para mí:

fastboot -S 512M flash system system.img  

Sin embargo, parece que trató de forzar su imagen de 2 GB a un tamaño que (1) podría no ser posible para que se rellene y (2) no sea el tamaño que se supone que debe ser la partición del sistema de su dispositivo.

  • Con respecto al punto n. ° 1, en mi experiencia, no contaría con las frágiles herramientas de compilación de Android para quejarme si les pides que hagan algo en lo que fracasarán, y es posible que lo tengan aquí.

  • Con respecto al punto # 2, no creo que no puedas hacer eso; Se necesitarí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 /systemera 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 despojada de cualquier exceso de grasa, como grandes bolsas de datos vacíos: un " archivo de imagen disperso " (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 viejo archivo Léame que alguien escribió para una colección de herramientas debería ayudar a entender cómo va el proceso.

Salud.

naki
fuente
1
Gracias por responder. En cuanto a sus preguntas, (1) no, no había max-download-nada en la salida de getvar. (2) Tendré en cuenta la -Sopción en mis futuros flashes: tal como está, una vez que arranqué, me convertí en root (mediante la recompilación de mi kernel) y ddsuperé la antigua partición del sistema, por lo que si funcionar con -S funcionaría tengo que esperar a mis próximas pruebas (3) Intenté con imágenes dispersas, obtuve el mismo resultado (es decir, fastbootinformó que el parpadeo estaba bien, pero la partición del sistema estaba en mal estado).
ttsiodras
1
@ttsiodras No hay problema. Aprendí algunas cosas en el proceso. (1) Ah, está bien. Dudaba que lo hiciera, ya que al menos en mi dispositivo usando la compilación de fastboot que instalé, esa variable se imprime primero en la lista (gracias, por cierto, por demostrar que allse puede pasar a getvar, eso es útil). (2) Ohh, está bien. Si funciona, háganoslo saber. (3) ¡Vaya! No me di cuenta de eso. Es mucho texto, lo siento. ¿Eso fue mencionado en tus publicaciones? (¿Fue como el comando make_ext4fs que sugerí, con -sla longitud completa de 2 GiB especificada?) Quizás la tableta no maneja archivos dispersos.
naki
1
(3) sí, pasé -sa 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 -Sopción en arranque rápido 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ó su montaje, pero los archivos dentro de ella ... se corrompieron al azar, dependiendo de si sus sectores se quemaron o no).
ttsiodras
2

Con mi Moto GI creé una copia de seguridad usando dd como lo hiciste. Necesitaba restaurar mi partición del sistema el otro día, así que inicié TWRP (no lo flasheé, simplemente inicié la imagen en la RAM). Luego usé adb para conectarme mientras TWRP se estaba ejecutando y simplemente empujé la img que hice con dd a mi tarjeta SD y luego usé dd para escribir la imagen en la partición del sistema.

Mira los videos que hice sobre esto aquí: https://youtu.be/BHCamV-sHx0?list=PLcUid3OP_4OVI1Rtuwxk1RjABh1PxXXQq

Metalx1000
fuente
Desafortunadamente, eso no me ayuda: no puedo recuperar mi tableta sin importar la combinación de teclas que probé (en contraste, la obtuve de inmediato en mi MotoG2, por lo que la recuperación de esta tableta está manchada de alguna manera). Puedo flashear la partición de recuperación (ya que flashboot está operativo) pero no tengo recovery.imgAsus, y tampoco existe CWM o TWRP (para un ME103K).
ttsiodras