Cercando di eseguire il flashing di un system.img ho scattato con dd - fallito

Ragazzo UNIX di lunga data qui, ma relativamente nuovo nel mondo di Android. Continuare a leggere.

EPISODIO 1: un nuovo backup (speravo)

Di recente ho acquistato un Asus MemoPAD (ME103K); Quindi sono diventato root e ho preso ddun'immagine della systempartizione di sola lettura sulla scheda SD esterna:

$ 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

Le dimensioni (esattamente 2GiB) erano un po 'sospette - potrebbe essere che ciò fosse dovuto alla partizione FAT32 sulla scheda SD?

No, non è stato - tune2fs -lrivelato che si trattava davvero di un'immagine EXT4 valida, dimensionata esattamente a 2GiB, che è passata fsck -fsenza errori. E fastboot(dalla macchina linux collegata al tablet) ha consentito, dopo 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

Quella dimensione, in effetti, è di 2 GB:

linuxbox# python2 -c 'print 0x0000000080000000'
2147483648

Quindi, tutto bene - Ho un backup dell'immagine. Ora per testare il ripristino.

Provo a eseguire il flashing di system.img sul tablet - per essere sicuro di poter recuperare da qualsiasi cosa, il tipo di backup a prova di proiettile che facciamo nel mondo Unix ( ad esempio ripristinare i contenuti di un'unità tramitedd if=backup.image of=/dev/sdXXX ).

Tutto ciò che riguarda adbe fastbootfunziona perfettamente - quindi provo ...

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. Scarico e costruisco la android-tools-5.1.1mia distribuzione da fonti, aggiungendo informazioni di debug e passo nel debugger per vedere questo errore:

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

Interessante - anche se io sono in una macchina a 64 bit, a quanto pare ci sono questioni che trasformano la dimensione del file "negativo" (in un mondo a 32 bit, la dimensione del file della mia immagine, 2 ^ 31, è infatti considerato negativo - per essere esatti, -2147483648.

OK, bene - come fanno a far lampeggiare file di immagini di grandi dimensioni in Android?

Googling, ricerca - scopre che usano questo make_ext4fsstrumento, che crea immagini flashable. In realtà fa parte di ciò che ho appena compilato, quindi potrei anche 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

Fantastico, quindi apparentemente posso costruire immagini di sistema da semplici cartelle vecchie. Il cielo sarà il mio limite - Sarò in grado di aggiungere tutto ciò che voglio a questa immagine.

Bruciamolo ...

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

Ho aspettato 1 ora prima di colpire quel Ctrl-C. E ha dovuto spegnere e riaccendere il tablet, che è stato riavviato in modalità fastboot.

Questo non sembra buono.

Cosa succede se creo un'immagine più piccola? Forse i 2 GB sono in qualche modo un problema e questa partizione non è utilizzata a piena capacità - ha spazio libero:

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, questo sembra molto promettente (e ci sono voluti solo 5 minuti). Immagino di poter ora riavviare e tutto dovrebbe essere normale, sì?

No :-)

Non mi dispiace un dispositivo muratura temporaneamente, finché io non arrivare a controllarlo alla fine (le macchine che io non sono un maestro di, sono macchine non mi interessa per operare ;-)

Qualche idea su cosa ho fatto di sbagliato e cosa posso fare per risolvere questo problema?

Grazie in anticipo.

PS Ho controllato la pagina di supporto di Asus per il mio tablet: forniscono solo i sorgenti per il kernel e il file .zip over-the-air. Che a sua volta contiene un backup a livello di file system dalla radice, ovvero la systemcartella esiste come una cartella, non un'immagine, non è un file system.imgche posso eseguire il flashing, quindi non mi aiuta molto.

EPISODIO 2: Attacco degli Stivali personalizzati

In assenza di qualsiasi tipo di recovery.imgAsus (perché un produttore dovrebbe preoccuparsi di pubblicare un fast-boot-flashable recovery.img? Perché davvero ...) e un'assenza simile sulle immagini di recupero dai siti CWM e TWRP ... Sono rimasto a combattere tutto solo.

Per fortuna, il file di aggiornamento Over-the-air di Asus include al suo interno ...

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

... l'immagine di avvio del mio tablet. Ora forse - solo forse - posso fare qualcosa con questo.

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

Espansione del ramdisk ...

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

Ho impostato default.propper essere root all'avvio del kernel:

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

Ho anche copiato /system/bin/sh( dal file .zip Asus over-the-air ) in /sbin/sh. Ho fatto lo stesso con busybox - strumento abbastanza utile.

E reimballato il 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

abootimgeffettivamente fallito la prima volta che eseguo questo, dal momento che è bootimg.cfgstato necessario aggiornare - il bootsizeparametro ha dovuto essere modificato, poiché il pacchetto ora è più grande. abootimgsegnala ciò di cui ha bisogno, quindi è abbastanza facile.

E ora avvio la mia immagine personalizzata ...

linuxbox# fastboot boot new_boot_busybox.img

... e testimonia quanto segue ...

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

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

Hmm ... Forse adbd non è eseguito come root?

linuxbox# adb root
restarting adbd as root

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

Bene ... ho hexedit adbd e patch / system / bin / sh per essere / sbin / sh (ho copiato / system / bin / sh dall'immagine OTA nei rootfs di initrd): riavvio, avvio rapido ...

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

Darn. Questa cosa è in grado di fare qualcosa?

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

È ... vediamo:

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, quindi / il sistema è montato. Posso vedere cosa c'è dentro?

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

Cosa ... Forse posso controllare cosa contiene / proc / kmsg (cosa "dmesg" produrrebbe)

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

No, ho bisogno di essere root per farlo.

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

E anche quello.

Questo si sta rivelando un bel rompicapo ...

Episodio 3: Return of the Shell.

Se mai avessi avuto la possibilità di risolverlo, dovevo prima capire perché la shell non funzionava. adbdstesso stava rispondendo, quindi è stato avviato sul lato tablet - ma non è stato possibile eseguire la shell, anche quando l'ho modificata con la patch per invocare un file ( /sbin/sh) che io stesso ho posizionato nell'immagine di avvio - essendo sicuro al 100% che avesse le autorizzazioni appropriate ed era accessibile dall'account shell(id = 2000) che adbdutilizza.

Che ha lasciato solo una spiegazione - SELinux "gabbie".

Quindi ho controllato come è adbdstato avviato dalla mia immagine di avvio 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 ho provato un ovvio cambiamento:

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

Ho reimballato e, con mia grande soddisfazione, ho visto ...

linuxbox# adb shell
$ 

Finalmente ho avuto accesso al tablet - da "dentro".

Controllando il sistema / montato, divenne chiaro che il processo di lampeggiamento - anche se fastboot flash system ...riferiva che tutto andava bene - era fallito in modo spettacolare . Era una meraviglia che la partizione fosse montata in primo luogo.

Ciò ha spiegato perché il tablet non si stava avviando e mi ha dato l'idea finale che ha risolto il problema.

Avevo bisogno di avviare il tablet in modo che usasse la mia copia originale della partizione / system, ma a questo punto, anche se avevo accesso alla shell, non ero root - ( le modifiche che ho fatto default.propsono apparentemente ignorate dal kernel Asus - Dovrò ricompilarlo presto ... ) in modo da non poter montare la sdcard esterna e ddsulla mia buona copia.

Ma avevo la mia immagine di avvio, il che significava che potevo modificare l' /fstab.qcominterno e farlo:

Linea originale che diceva al tablet come montare / sistema

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

La mia modifica

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

... e di nuovo nella mia scatola di Linux, ho ddaggiunto il backup originale della partizione di sistema del tablet alla seconda partizione della mia scheda SD esterna, che ho creato tramite gpartedesattamente 2 GB.

È stato così: il tablet è stato avviato dalla mia scheda SD esterna.

EDIT : Il viaggio è continuato - alla fine ho patchato e compilato il mio kernel e sono diventato root .

Sembra che tu abbia già trovato una soluzione al tuo problema (c'è molto testo da leggere in questa pagina), ma sembra che questo probabilmente avrebbe potuto essere risolto molto più semplicemente.

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

Tra queste variabili, il tablet ha restituito una max-download-sizevariabile? In tal caso, ciò potrebbe aver fornito un avvertimento, in via definitiva, che il processo di lampeggiamento potrebbe avere alcuni problemi con un'immagine così grande. L'attuale codice di avvio rapido è concepito per aggirare un valore max-download-sizetroppo piccolo, ma ho riscontrato il tuo stesso errore anche quando l'immagine è più piccola di quella che il dispositivo dice di poter gestire, quindi in realtà il punto è piuttosto discutibile.

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

Quindi, in ogni caso, sembra che qui, per qualsiasi motivo, non sia possibile eseguire il flash. Se tu ed io abbiamo ragione, e si tratta di dimensioni (il tablet ha solo 1 GB di RAM, e presumibilmente la maggior parte dei dispositivi tenta di leggere l'intera immagine nella RAM prima del flashing ), è qui che penso che la semplice regolazione dell'aggiunta -Sdell'opzione a fastboot potrebbe aver corretto il tuo flash come ha fatto per me:

fastboot -S 512M flash system system.img  

Invece, tuttavia, sembra che tu abbia provato a forzare la tua immagine da 2 GB in una dimensione che (1) potrebbe non essere possibile per essere inserita e (2) non è la dimensione che dovrebbe essere la partizione di sistema del tuo dispositivo.

• Per quanto riguarda il punto n. 1, nella mia esperienza, non conterei sui fragili strumenti di build di Android per lamentarsi se gli chiedi di fare qualcosa per cui falliranno, ed è possibile che possano avere qui.

• Per quanto riguarda il punto 2, non credo che tu non possa semplicemente farlo; sarebbero necessari ulteriori passaggi per utilizzare una diversa dimensione della partizione di sistema.

Supponendo che il tablet si aspetti file di immagini sparse, credo che il comando che volevi provare invece di make_ext4fs -l 1536M new_system.img /systemera make_ext4fs -l 2048M -s new_system.img /system. Il comando modificato renderebbe un'immagine che si gonfia alla dimensione corretta, ma viene memorizzata temporaneamente spogliata di qualsiasi grasso in eccesso come grandi sacche di dati vuoti: un " file di immagini sparse " (vedi la pagina a cui ho collegato in precedenza per ulteriori informazioni su di essi; Non ho abbastanza reputazione su questo sito per ripetere il collegamento).

Questo vecchio readme scritto da qualcuno per una raccolta di strumenti dovrebbe aiutare a capire come va il processo.

Saluti.

Con Moto GI ho creato un backup usando dd come hai fatto tu. Avevo bisogno di ripristinare la mia partizione di sistema l'altro giorno, quindi ho avviato TWRP (non l'ho fatto flash, ho appena avviato l'immagine su RAM). Ho quindi usato adb per connettermi mentre TWRP era in esecuzione e ho appena trasferito l'img che ho creato con dd sulla mia scheda SD e quindi ho usato dd per scrivere l'immagine nella partizione di sistema.

Guarda i video che ho fatto su questo qui: https://youtu.be/BHCamV-sHx0?list=PLcUid3OP_4OVI1Rtuwxk1RjABh1PxXXQq