Essayer de flasher un system.img que j'ai pris avec dd - échec

16

Un gars UNIX de longue date ici, mais relativement nouveau dans le monde d'Android. Continuer à lire.

EPISODE 1: Une nouvelle sauvegarde (j'espérais)

J'ai récemment acheté un Asus MemoPAD (ME103K); Je suis ensuite devenu root et j'ai pris une ddimage de la systempartition en lecture seule sur la carte SD externe:

$ 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

La taille (exactement 2 Go) était un peu suspecte - se pourrait-il que ce soit à cause de la partition FAT32 sur la carte SD?

Non, cela n'a pas été - a tune2fs -lrévélé qu'il s'agissait bien d'une image EXT4 valide, exactement à la taille de 2 Go, qui a réussi fsck -fsans aucune erreur. Et fastboot(à partir de la machine Linux attachée à la tablette), après 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

Cette taille est en effet de 2 Go:

linuxbox# python2 -c 'print 0x0000000080000000'
2147483648

Donc, tout va bien - j'ai une sauvegarde de l'image. Maintenant pour tester la restauration.

J'essaie de flasher le system.img sur la tablette - pour m'assurer que je peux récupérer de tout, le type de sauvegarde à l'épreuve des balles que nous faisons dans le monde Unix ( par exemple restaurer le contenu d'un lecteur viadd if=backup.image of=/dev/sdXXX ).

Tout ce qui concerne adbet fastbootfonctionne parfaitement - alors j'essaie ...

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. Je télécharge et compile android-tools-5.1.1ma distribution à partir de sources, en ajoutant des informations de débogage - et j'interviens dans le débogueur, pour voir cet échec:

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

Échec dû à une taille négative!

Intéressant - même si je suis dans une machine 64 bits, apparemment il y a des problèmes qui transforment la taille du fichier « négatif » (dans un monde 32bit, la taille du fichier de mon image, 2 ^ 31, est en effet considéré comme négatif - pour être exact, -2147483648.

OK, très bien - comment flashent-ils de gros fichiers d'images dans Android?

Googler, rechercher - il s'avère qu'ils utilisent cet make_ext4fsoutil, qui crée des images flashable. En fait, cela fait partie de ce que je viens de compiler, donc je peux aussi bien l'utiliser:

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

Cool - donc je peux apparemment construire des images système à partir de vieux dossiers simples. Le ciel sera ma limite - je pourrai ajouter tout ce que je veux à cette image.

Brûlons-le ...

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

J'ai attendu 1h avant de frapper ce Ctrl-C. Et a dû redémarrer la tablette, qui a redémarré en mode fastboot.

Ce n'est pas beau.

Et si je crée une image plus petite? Peut-être que les 2 Go sont en quelque sorte un problème, et cette partition n'est pas utilisée à pleine capacité - elle a de l'espace 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, cela semble très prometteur (et n'a pris que 5 minutes). Je suppose que je peux maintenant redémarrer et tout devrait être normal, non?

Non :-)

entrez la description de l'image ici

Je ne me dérange pas un dispositif murée temporairement, tant que je ne me le contrôler à la fin (machines que je ne suis pas un maître, sont des machines que je ne tiens pas à faire fonctionner ;-)

Des idées sur ce que j'ai fait de mal et ce que je peux faire pour y remédier?

Merci d'avance.

PS J'ai vérifié la page de support Asus pour ma tablette - ils ne fournissent que les sources pour le noyau et le fichier .zip Over-the-air. Cela contient à son tour une sauvegarde au niveau du système de fichiers à partir de la racine - c'est-à-dire que le systemdossier existe là-dedans comme juste un dossier, pas une image, pas une system.imgque je peux flasher - donc cela ne m'aide pas vraiment.

EPISODE 2: Attaque des bottes personnalisées

En l'absence de toute sorte d' recovery.imgAsus (pourquoi un fabricant prendrait la peine de publier un fastboot-flashable recovery.img? Pourquoi en effet ...) et une absence similaire sur les images de récupération des sites CWM et TWRP ... seul.

Heureusement, le fichier de mise à jour Over-the-air d'Asus comprend à l'intérieur ...

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'image de démarrage de ma tablette. Maintenant peut-être - juste peut-être - je peux faire quelque chose avec ça.

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

Extension du disque virtuel ...

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

J'ai configuré default.proppour être root lorsque le noyau démarre:

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

J'ai également copié /system/bin/shpartir du fichier Asus .zip en direct ) dans /sbin/sh. J'ai fait la même chose avec busybox - un outil très pratique.

Et remballé le 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 fait, j'ai échoué la première fois que je lance ceci, car il bootimg.cfga dû être mis à jour - le bootsizeparamètre a dû être changé, car le package est plus gros maintenant. abootimgrapporte ce dont il a besoin, donc c'est assez facile.

Et maintenant, je démarre mon image personnalisée ...

linuxbox# fastboot boot new_boot_busybox.img

... et assistez à ce qui suit ...

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

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

Hmm ... Peut-être que adbd n'est pas exécuté en tant que root?

linuxbox# adb root
restarting adbd as root

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

Très bien ... je hexedit adbd, et patch / system / bin / sh pour être / sbin / sh (j'ai copié le / system / bin / sh de l'image OTA vers les rootfs de l'initrd): Reboot, fastboot ...

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

Zut. Cette chose est-elle capable de faire quoi que ce soit?

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

C'est ... voyons:

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, donc / le système est monté. Puis-je voir ce qu'il y a à l'intérieur?

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

Qu'est-ce que ... Peut-être que je peux vérifier ce que contient / proc / kmsg (ce que "dmesg" afficherait)

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

Non, je dois être root pour ça.

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

Et cela aussi.

Cela s'avère être un véritable casse-tête ...

ttsiodras
la source
2
La seule bonne chose que vous n'avez pas faite ici (et que vous auriez dû faire) est de flasher une récupération personnalisée, puis d'effectuer une sauvegarde nandroid des partitions. C'est l'une des méthodes à l'épreuve des balles pour récupérer des appareils à partir d'un tel état de brique. Ce Over-the-air.zip (zip OTA) est un zip flashable de récupération, c'est-à-dire qu'il doit être flashé lors du démarrage dans Recovery et ils suivent un format d'emballage différent mais atteignent le même objectif. Pour faire court, flashez une récupération personnalisée (ou démarrez-la en stock), flashez la ROM stock, puis expérimentez autant que vous le souhaitez.
Firelord
1
@Firelord: C'est la chose - même s'il fastbootest toujours opérationnel (répond très bien aux demandes) et je peux donc graver n'importe quelle image de récupération, (a) J'ai recherché et trouvé aucune image de récupération CWM ou TWRP pour ME103K - Je ne suppose pas qu'il y ait "générique" dont vous parlez, n'est-ce pas? (b) La mise hors tension, en appuyant sur le bouton d'alimentation + le volume bas ne fait pas apparaître l'image de récupération - je viens tout juste de passer à l'état de démarrage rapide. Mo idée pourquoi. En fait, je n'ai jamais vu le processus de récupération (un peu curieux de le voir) ...
ttsiodras
1
Essayez d'autres combinaisons de boutons telles que Power + Vol Up + Vol Down pour démarrer en mode de récupération. Si vous avez accès à Stock Recovery ZIP, il peut y avoir un fichier image de Stock Recovery quelque part que vous pouvez flasher à partir de fastboot ou y démarrer directement ( fastboot boot <FILE>.img), puis flasher le fichier ZIP entier. Sinon, voyez s'il existe (sur le Web) les fichiers ROM d'origine qui peuvent être flashés à l'aide de fastboot.
Firelord
1
@Firelord: Non, Asus ne fournit pas de fichier recovery.zip. Dans le fichier OTA, il n'y a rien .img-y ( unzip -l UL-K01E-WW-12.16.1.12-user.zip | grep recoveryne montre que quelques scripts shell - je vais y jeter un œil, mais il n'y en a certainement pas recovery.img). La recherche sur Google n'a pas aidé non plus - il n'y a aucune image de récupération de cette tablette nulle part ... Je suppose que je devrai attendre une sorte d'âme pour ddleur partition de récupération et la partager?
ttsiodras

Réponses:

7

Épisode 3: Le retour de la coquille.

Si jamais j'avais une chance de résoudre ce problème, je devais d'abord comprendre pourquoi le shell ne fonctionnait pas. adbdlui-même répondait, donc il a été démarré du côté de la tablette - mais il n'a pas pu exécuter le shell, même lorsque je l'ai piraté pour appeler un fichier ( /sbin/sh) que j'ai moi-même placé dans l'image de démarrage - étant sûr à 100% qu'il l'avait les autorisations appropriées et était accessible à partir du compte shell(id = 2000) qui adbdutilise.

Ce qui n'a laissé qu'une seule explication - les "cages" SELinux.

J'ai donc vérifié comment a adbdété démarré à partir de mon image de démarrage 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

... et essayé un changement évident:

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

J'ai remballé, et à ma grande satisfaction, j'ai vu ...

linuxbox# adb shell
$ 

J'ai finalement eu accès à la tablette - de "l'intérieur".

En vérifiant le système / monté, il est devenu clair que le processus de clignotement - bien que fastboot flash system ...rapporté que tout allait bien - avait échoué de manière spectaculaire . C'était une merveille que la cloison ait été montée en premier lieu.

Cela a expliqué pourquoi la tablette ne démarrait pas et m'a donné l'idée finale qui a résolu le problème.

J'avais besoin de démarrer la tablette pour qu'elle utilise ma copie vierge de la partition / system, mais à ce stade, même si j'avais accès au shell, je n'étais pas root - ( les modifications que j'ai apportées dans default.propsont apparemment ignorées par le noyau Asus - Je vais devoir le recompiler bientôt ... ) donc je n'ai pas pu monter la carte SD externe et ddsur ma bonne copie.

Mais j'avais ma propre image de démarrage - ce qui signifiait que je pouvais modifier l' /fstab.qcomintérieur, et faire ceci:

Ligne originale expliquant à la tablette comment monter / système

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

Ma rédaction

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

... et de retour dans ma boîte Linux, j'ai ddsauvegardé la sauvegarde vierge de la partition système de la tablette sur la deuxième partition de ma carte SD externe - que j'ai créée via gpartedpour exactement 2 Go.

Cela l'a fait - la tablette a démarré à partir de ma carte SD externe.

EDIT : Le voyage s'est poursuivi - j'ai finalement patché et compilé mon propre noyau et je suis devenu root .

ttsiodras
la source
2
Je jure sur l'épisode 4, j'aurais offert une prime si cette réponse n'avait pas été publiée, pour le plaisir de tous ces épisodes. C'est bon de voir que vous avez résolu votre problème par vous-même. : D
Firelord
2
@Firelord: Merci, mon pote. Dans le processus, je pense que j'ai fait quelque chose de plutôt cool - j'ai démarré ma tablette sans toucher à l'intérieur ... l'image de démarrage vient de l'extérieur (sur fastboot boot ...) et la /systempartition est sur la carte SD, ajustable à tout ce que je veux. Un peu comme, démarrer un PC à partir d'une clé USB :-)
ttsiodras
4

Il semble que vous ayez déjà trouvé une sorte de solution à votre problème (il y a beaucoup de texte à lire sur cette page), mais il semble que cela aurait probablement pu être résolu beaucoup plus simplement.

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

Parmi ces variables, votre tablette a-t-elle renvoyé une max-download-sizevariable? Si c'est le cas, cela pourrait avoir fourni un avertissement, tout simplement, que le processus de clignotement pourrait avoir des problèmes avec une image aussi grande. Le code de démarrage rapide actuel est conçu pour contourner un code max-download-sizetrop petit, mais j'ai rencontré votre même erreur même lorsque l'image est plus petite que ce que l'appareil dit qu'il peut gérer, donc en fait, le point est un peu théorique, je suppose.

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

Donc, de toute façon, il semble ici que, pour une raison quelconque, vous ne pouvez pas flasher. Si vous et moi avons raison, et qu'il s'agit de la taille (votre tablette n'a que 1 Go de RAM, et la plupart des appareils essaient de lire l'image entière dans la RAM avant de clignoter ), c'est là que je pense que le simple ajustement de l'ajout de l' -Soption fastboot pourrait avoir corrigé votre flash comme il l'a fait pour moi:

fastboot -S 512M flash system system.img  

Au lieu de cela, cependant, il semble que vous ayez essayé de forcer votre image de 2 Go à une taille qui (1) pourrait ne pas être possible pour qu'elle soit remplie et (2) ne soit pas la taille que la partition système de votre appareil est censée être.

  • En ce qui concerne le point n ° 1, d'après mon expérience, je ne compterais pas sur les outils de construction Android fragiles pour se plaindre si vous leur demandez de faire quelque chose qu'ils échoueront, et il est possible qu'ils aient ici.

  • En ce qui concerne le point n ° 2, je ne pense pas que vous ne puissiez pas simplement faire cela; des étapes supplémentaires seraient nécessaires pour utiliser une taille de partition système différente.

En supposant que votre tablette attend des fichiers d'image clairsemés, je pense que la commande que vous vouliez essayer au lieu de l' make_ext4fs -l 1536M new_system.img /systemétait make_ext4fs -l 2048M -s new_system.img /system. La commande ajustée ferait une image qui se gonfle à la bonne taille, mais est stockée temporairement débarrassée de tout excès de graisse comme de grosses poches de données vides: un " fichier d'image clairsemée " (voir la page que j'ai liée plus tôt pour plus d'informations à leur sujet; Je n'ai pas assez de réputation sur ce site pour répéter le lien).

Ce vieux fichier lisez-moi que quelqu'un a écrit pour une collection d'outils devrait aider à comprendre le déroulement du processus.

À votre santé.

naki
la source
1
Merci de répondre. Quant à vos questions, (1) non, il n'y avait max-download-rien dans la sortie de getvar. (2) Je garderai à l'esprit l' -Soption dans mes futurs clignotements - comme c'est le cas, une fois que j'ai démarré, je suis devenu root (via la recompilation de mon noyau) et dd-ed sur l'ancienne partition système, donc si le clignotement avec -S fonctionnerait, dois attendre mes prochains tests (3) J'ai essayé avec des images clairsemées, j'ai obtenu le même résultat (c'est-à-dire fastbootque le flash était correct, mais la partition système était foirée).
ttsiodras
1
@ttsiodras Aucun problème. J'ai appris certaines choses au cours du processus. (1) Ah, d'accord. Je doutais que ce soit le cas, comme au moins sur mon appareil utilisant la version de fastboot que j'ai installée, cette variable est imprimée en premier dans la liste (merci, btw, d'avoir démontré qu'elle allpeut être transmise à getvar - c'est utile). (2) Oh, d'accord. Si cela fonctionne, faites-le nous savoir. (3) Oups! Je ne l'ai pas remarqué. C'est beaucoup de texte, désolé. Cela a-t-il été mentionné dans vos messages? (Était-ce comme la commande make_ext4fs que j'ai suggérée, avec -sla longueur complète de 2 Gio spécifiée?) Peut-être que la tablette ne gère pas les fichiers épars.
naki
1
(3) oui, je suis passé -sà make_ext4fs - fastboot a signalé 'OK' pour la gravure, mais / system a été foiré. Ma théorie est que, comme vous l'avez dit, quelque chose de plus grand que la mémoire de la tablette (1 Go) ne fonctionnerait pas et nécessitait l' -Soption de fastboot pour fonctionner correctement (ce qui explique l'état à moitié cassé - la partition a été montée parce que la première partie de l'image était en mémoire et a été réellement gravée, ce qui lui a permis d'être montée - mais les fichiers à l'intérieur ont été ... corrompus au hasard, selon que leurs secteurs ont été gravés ou non).
ttsiodras
2

Avec mon Moto GI, j'ai créé une sauvegarde en utilisant dd comme vous l'avez fait. J'avais besoin de restaurer ma partition système l'autre jour, alors j'ai démarré TWRP (je ne l'ai pas flashé, j'ai juste démarré l'image sur la RAM). J'ai ensuite utilisé adb pour me connecter pendant que TWRP était en cours d'exécution et j'ai simplement poussé l'img que j'ai fait avec dd sur ma carte SD, puis j'ai utilisé dd pour écrire l'image sur la partition système.

Découvrez les vidéos que j'ai faites à ce sujet ici: https://youtu.be/BHCamV-sHx0?list=PLcUid3OP_4OVI1Rtuwxk1RjABh1PxXXQq

Metalx1000
la source
Malheureusement, cela ne m'aide pas - je ne peux pas accéder à la récupération de ma tablette, quelle que soit la combinaison de touches que j'ai essayée (en revanche, je l'ai immédiatement sur mon MotoG2 - donc la récupération de cette tablette est arrosée d'une manière ou d'une autre). Je peux flasher la partition de récupération (car flashboot est opérationnel) mais je n'en ai pas recovery.imgd'Asus, et il n'y a pas non plus de CWM ou TWRP (pour un ME103K).
ttsiodras