Tentando piscar um system.img que tirei com dd - falhando

Há muito tempo o cara do UNIX aqui, mas relativamente novo no mundo do Android. Continue lendo.

EPISÓDIO 1: Um novo backup (eu esperava)

Eu comprei recentemente um Asus MemoPAD (ME103K); Tornei-me root e tirei uma ddimagem da systempartição somente leitura para o cartão SD externo:

$ 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

O tamanho (exatamente 2GiB) era um pouco suspeito - poderia ser por causa da partição FAT32 no cartão SD?

Não, não foi tune2fs -lrevelado que se tratava de uma imagem EXT4 válida, exatamente dimensionada em 2GiB, que passou fsck -fsem nenhum erro. E fastboot(da máquina linux conectada ao tablet) concordou, após um 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

Esse tamanho é de fato 2 GB:

linuxbox# python2 -c 'print 0x0000000080000000'
2147483648

Então, está tudo bem - eu tenho um backup da imagem. Agora, teste para restaurá-lo.

Eu tento atualizar o system.img de volta para o tablet - para garantir que eu possa me recuperar de qualquer coisa, o tipo de backup à prova de bala que fazemos no mundo Unix ( por exemplo, restaurar o conteúdo de uma unidade viadd if=backup.image of=/dev/sdXXX ).

Tudo relacionado adbe fastbootfunciona perfeitamente - então eu tento ...

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. Transfiro e construo a android-tools-5.1.1distribuição a partir das fontes, adicionando informações de depuração - e passo no depurador para ver esta falha:

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

Interessante - mesmo estando em uma máquina de 64 bits, aparentemente existem problemas que tornam o tamanho do arquivo "negativo" (em um mundo de 32 bits, o tamanho da minha imagem, 2 ^ 31, é de fato considerado negativo - para ser exato,) -2147483648.

OK, tudo bem - como eles exibem arquivos de imagem grandes no Android?

Pesquisando, pesquisando - eles usam essa make_ext4fsferramenta, que cria imagens flexíveis. Na verdade, é parte do que acabei de compilar, então é melhor usá-lo:

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

Legal - para que eu possa aparentemente criar imagens do sistema a partir de pastas antigas simples. O céu será meu limite - poderei adicionar o que quiser a esta imagem.

Vamos queimar ...

linuxbox# fastboot flash system new_system.img
erasing 'system'...
OKAY [  0.064s]
sending 'system' (2088960 KB)...
^C

Eu esperei por 1h antes de pressionar Ctrl-C. E teve que ligar e desligar o tablet, que inicializou novamente no modo de inicialização rápida.

Isso não parece bom.

E se eu criar uma imagem menor? Talvez os 2 GB sejam de algum modo um problema e essa partição não seja usada com capacidade total - ela possui espaço livre:

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, isso parece muito promissor (e levou apenas 5 minutos). Acho que agora posso reiniciar e tudo deve estar normal, sim?

Não :-)

Não me importo de um dispositivo temporariamente emparedada, enquanto eu não conseguir controlá-lo no final (máquinas que não sou um mestre, são máquinas que não se importam para operar ;-)

Alguma idéia do que fiz de errado e o que posso fazer para corrigir isso?

Desde já, obrigado.

PS Verifiquei a página de suporte da Asus no meu tablet - eles fornecem apenas as fontes para o kernel e o arquivo .zip over-the-air. Por sua vez, ele contém um backup no nível do sistema de arquivos da raiz - ou seja, a systempasta existe lá apenas como uma pasta, não como uma imagem, nem como uma imagem system.imgque eu possa exibir -, o que realmente não me ajuda.

EPISÓDIO 2: Ataque das botas personalizadas

Na ausência de qualquer tipo de produto recovery.imgda Asus (por que um fabricante se preocuparia em publicar um fastboot-flashable recovery.img? Por que de fato ...) e uma ausência semelhante em imagens de recuperação dos sites CWM e TWRP ... Eu estou à esquerda para combater tudo sozinho.

Felizmente, o arquivo de atualização aérea da Asus inclui dentro dele ...

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

... a imagem de inicialização do meu tablet. Agora talvez - apenas talvez - eu possa fazer algo com isso.

linuxbox$ mkdir rootfs
linuxbox$ cd rootfs
linuxbox$ abootimg -x /path/to/boot.img
linuxbox$ ls -l
bootimg.cfg
initrd.img
zImage

Expandindo o ramdisk ...

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

Eu configurei default.proppara ser root quando o kernel é inicializado:

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

Também copiei /system/bin/sh( do arquivo .us zip over-the-air da Asus ) para /sbin/sh. Eu fiz o mesmo com o busybox - ferramenta bastante útil.

E reembalou o 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

abootimgrealmente falhou na primeira vez em que eu executei isso, pois bootimg.cfgprecisava ser atualizado - o bootsizeparâmetro precisava ser alterado, pois o pacote agora é maior. abootimgrelata o que precisa, de modo que é fácil o suficiente.

E agora, eu inicializo minha imagem personalizada ...

linuxbox# fastboot boot new_boot_busybox.img

... e testemunhe o seguinte ...

linuxbox# adb logcat
- exec '/system/bin/sh' failed: Permission denied (13) -

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

Hmm ... Talvez o adbd não seja executado como root?

linuxbox# adb root
restarting adbd as root

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

Tudo bem ... Eu hexeditou o adbd e o patch / system / bin / sh deve ser / sbin / sh (copiei o / system / bin / sh da imagem OTA para os rootfs do initrd): Reinicie, fastboot ...

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

Droga. Essa coisa é capaz de fazer alguma coisa?

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

É ... vamos 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, então / system está montado. Posso ver o que está dentro?

linuxbox# adb pull /system
remote object '/system' does not exist

O que ... Talvez eu possa verificar o que o / proc / kmsg contém (o que "dmesg" produziria)

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

Não, eu preciso ser raiz para fazer isso.

linuxbox# adb push /sbin/sh /system/bin/sh
failed to copy '/sbin/sh' to '/system/bin/sh': Permission denied

E isso também.

Isso está se tornando um quebra-cabeça ...

Episódio 3: Return of the Shell.

Se eu já tive alguma chance de resolver isso, primeiro tive que descobrir por que o shell não estava funcionando. adbdestava respondendo, então foi iniciado no lado do tablet - mas não pôde executar o shell, mesmo quando eu o corrigi para invocar um arquivo ( /sbin/sh) que eu mesmo coloquei na imagem de inicialização - tendo 100% de certeza de que tinha as permissões apropriadas e estava acessível a partir da conta shell(id = 2000) adbdusada.

O que deixou apenas uma explicação - o SELinux "gaiolas".

Então eu verifiquei como adbdfoi iniciado a partir da minha imagem de inicialização 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 tentou uma mudança óbvia:

service adbd /sbin/adbd
    class core
    socket adbd stream 660 system system

Eu re-embalado, e para minha intensa satisfação, vi ...

linuxbox# adb shell
$ 

Finalmente consegui acesso ao tablet - de "dentro".

Verificando o sistema montado, ficou claro que o processo de piscar - apesar de ter fastboot flash system ...relatado que tudo estava ok - falhou espetacularmente . Foi uma maravilha que a partição tenha sido montada em primeiro lugar.

Isso explicou por que o tablet não estava inicializando e me deu a ideia final que resolveu o problema.

Eu precisava inicializar o tablet para que ele usasse minha cópia original da partição / system, mas neste momento, mesmo tendo acesso ao shell, eu não era root - ( as alterações que fiz default.propforam aparentemente ignoradas pelo kernel da Asus - Vou ter que recompilar em breve ... ) para não poder montar o sdcard externo e ddsobre minha boa cópia.

Mas eu tinha minha própria imagem de inicialização - o que significava que eu podia editar o /fstab.qcominterior e fazer o seguinte:

Linha original que informava ao tablet como montar / sistema

/dev/block/platform/msm_sdcc.1/by-name/system  /system  ext4 ro,barrier=1 wait

Minha edição

/dev/block/mmcblk1p2  /system ext4  rw,barrier=1 wait

... e de volta à minha caixa Linux, ddinstalei o backup primitivo da partição do sistema do tablet na 2ª partição do meu cartão SD externo - que criei gpartedpara ter exatamente 2 GB.

Foi isso - o tablet inicializou no meu cartão SD externo.

EDIT : A jornada continuou - eu finalmente consertei e compilei meu próprio kernel e me tornei root .

Parece que você já encontrou algum tipo de solução para o seu problema (há muito texto para ler nesta página), mas parece que isso provavelmente poderia ter sido resolvido de maneira muito mais simples.

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 essas variáveis, seu tablet retornou uma max-download-sizevariável? Nesse caso, isso pode ter fornecido um aviso direto de que o processo de piscar pode ter alguns problemas com uma imagem tão grande. O código atual do fastboot foi criado para solucionar um problema max-download-sizeque é muito pequeno, mas eu experimentei o mesmo erro mesmo quando a imagem é menor do que o dispositivo diz que é capaz de lidar, então, na verdade, o ponto é meio discutível, eu acho.

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

De qualquer maneira, parece que aqui, por qualquer motivo, você não consegue piscar. Se você e eu estamos certos, e é sobre o tamanho (seu tablet possui apenas 1 GB de RAM e, supostamente, a maioria dos dispositivos tenta ler toda a imagem na RAM antes de piscar ), é aqui que acho que o mero ajuste de adicionar a -Sopção fastboot pode ter corrigido seu flash como ele tem para mim:

fastboot -S 512M flash system system.img  

Em vez disso, no entanto, parece que você tentou forçar sua imagem de 2 GB a um tamanho que (1) talvez não seja possível inseri-la e (2) não é o tamanho que a partição de sistema do seu dispositivo deve ter.

• Em relação ao ponto 1, na minha experiência, eu não contaria com as frágeis ferramentas de construção do Android para reclamar se você pedir a elas que façam algo em que falharão, e é possível que elas tenham aqui.

• Quanto ao ponto 2, não acredito que você não possa fazer isso; etapas adicionais seriam necessárias para usar um tamanho de partição do sistema diferente.

Supondo que o seu tablet espere arquivos de imagem esparsos, acredito que o comando que você desejou experimentar make_ext4fs -l 1536M new_system.img /systemfoi o make_ext4fs -l 2048M -s new_system.img /system. O comando ajustado criaria uma imagem inflada no tamanho correto, mas é armazenada temporariamente sem qualquer excesso de gordura, como grandes bolsões de dados vazios: um " arquivo de imagem esparsa " (consulte a página à qual vinculei anteriormente para obter mais informações sobre elas; Não tenho reputação suficiente neste site para repetir o link).

Este antigo leia-me que alguém escreveu para uma coleção de ferramentas deve ajudar a entender como o processo ocorre.

Felicidades.

Com o meu Moto GI criei um backup usando dd como você fez. Eu precisava restaurar a partição do sistema no outro dia, então iniciei o TWRP (não o flash, apenas inicializei a imagem na RAM). Em seguida, usei o adb para conectar-me enquanto o TWRP estava em execução e apenas enviei o img que fiz com dd para o meu cartão SD e usei o dd para gravar a imagem na partição do sistema.

Confira os vídeos que fiz sobre isso aqui: https://youtu.be/BHCamV-sHx0?list=PLcUid3OP_4OVI1Rtuwxk1RjABh1PxXXQq