18 votes

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

J'ai longtemps travaillé sous UNIX, mais je suis relativement nouveau dans le monde d'Android. Lire la suite.

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

J'ai récemment acheté un Asus MemoPAD (ME103K) ; je suis alors devenu Root, et j'ai pris une dd de l'image en lecture seule system 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 2GiB) était un peu suspecte - se pourrait-il que ce soit à cause de la partition FAT32 sur la carte SD ?

Non, ce n'était pas tune2fs -l a révélé qu'il s'agissait en effet d'une image EXT4 valide, d'une taille exacte de 2GiB, qui a passé le test de l'image EXT4. fsck -f sans aucune erreur. Et fastboot (depuis la machine linux attachée à la tablette) a approuvé, après une 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, c'est effectivement 2GB :

linuxbox# python2 -c 'print 0x0000000080000000'
2147483648

Donc, tout va bien - j'ai une sauvegarde de l'image. Maintenant, je dois tester sa restauration.

J'essaie de flasher le system.img sur la tablette - pour être sûr de pouvoir récupérer n'importe quoi, le genre de sauvegarde à toute épreuve que l'on fait dans le monde Unix ( par exemple, restaurer le contenu d'un lecteur via dd if=backup.image of=/dev/sdXXX ).

Tout ce qui concerne adb y fastboot fonctionnent 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 construit le android-tools-5.1.1 de ma distribution à partir des sources, en ajoutant des informations de débogage - et passez dans le débogueur, pour voir cet échec :

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

Failure due to negative size!

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

Bon, d'accord - comment fait-on pour flasher des fichiers image volumineux dans Android ?

Googler, chercher - il s'avère qu'ils utilisent ceci make_ext4fs qui crée des images flashables. En fait, il fait partie de ce que je viens de compiler, alors autant 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 simples dossiers. 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 d'appuyer sur Ctrl-C. Et j'ai dû éteindre la tablette, qui a redémarré en mode fastboot.

Ça ne s'annonce pas bien.

Et si je construisais une image plus petite ? Peut-être que les 2 Go sont un problème, et que 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 que tout devrait être normal, oui ?

Non :-)

enter image description here

Ça ne me dérange pas d'avoir un appareil temporairement cassé, tant que je faire de la contrôler en fin de compte (les machines que je ne maîtrise pas sont des machines que je n'ai pas envie de faire fonctionner ;-)

Des idées sur ce que j'ai fait de mal et ce que je peux faire pour réparer ça ?

Merci d'avance.

P.S. J'ai vérifié la page d'assistance d'Asus pour ma tablette - ils ne fournissent que les sources du noyau et le fichier .zip Over-the-air. Ce dernier contient à son tour une sauvegarde au niveau du système de fichiers à partir de la racine - c'est-à-dire le fichier system existe là-dedans comme un simple dossier, pas comme une image, pas comme une system.img que je peux flasher - donc ça ne m'aide pas vraiment.

EPISODE 2 : L'attaque des bottes sur mesure

En l'absence de toute forme de recovery.img d'Asus (pourquoi un fabricant se donnerait-il la peine de publier un fichier flashable par fastboot). recovery.img ? Pourquoi en effet...) et une absence similaire sur les images de récupération des sites CWM et TWRP... Je dois me battre tout seul.

Heureusement, le fichier de mise à jour Over-the-air d'Asus inclut à 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 RAM...

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

J'ai mis en place default.prop pour être Root lorsque le noyau démarre :

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

J'ai aussi copié /system/bin/sh ( à partir du fichier .zip de l'Asus over-the-air. ) en /sbin/sh . J'ai fait la même chose avec busybox - outil très pratique.

Et j'ai réinstallé le fichier 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 a en fait échoué la première fois que j'ai lancé cette opération, puisque bootimg.cfg a dû être mis à jour - le bootsize Le paramètre a dû être modifié, car le paquet est plus grand maintenant. abootimg rapporte 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 assister à 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) -

Bien... J'ai hexedit adbd, et patch /system/bin/sh pour être /sbin/sh (j'ai copié le /system/bin/sh de l'image OTA dans le rootfs de l'initrd) : Reboot, fastboot...

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

Mince. Ce truc est capable de faire quelque chose ?

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

C'est... voyons voir :

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 /system es monté. Je peux voir ce qu'il y a dedans ?

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

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

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

Nah, j'ai besoin d'être Root pour faire ça.

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

Et ça aussi.

Cela s'avère être un sacré puzzle...

2 votes

La seule bonne chose que vous n'avez pas fait ici (et que vous auriez dû faire) est de flasher une restauration personnalisée et ensuite de prendre un nandroid sauvegarde des partitions à partir de celui-ci. C'est l'une des méthodes les plus fiables pour récupérer un appareil dans un tel état. Ce Over-the-air.zip (OTA zip) est un zip flashable de récupération, c'est-à-dire à flasher lors du démarrage de la récupération et ils suivent un format d'emballage différent mais atteignent le même objectif. Pour faire court, flashez une restauration personnalisée (ou démarrez dans la restauration d'origine), flashez la ROM d'origine et expérimentez autant que vous le souhaitez.

1 votes

@Firelord : C'est le truc - même si fastboot est 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 cherché et trouvé aucune image de récupération CWM ou TWRP pour ME103K - je suppose qu'il n'y a pas d'image "générique" à laquelle vous faites référence, n'est-ce pas ? (b) En éteignant l'appareil, en appuyant sur le bouton d'alimentation + le volume vers le bas, l'image de récupération ne s'affiche pas - j'arrive toujours à l'état de démarrage rapide. Je ne sais pas pourquoi. En fait, je n'ai jamais vu le processus de récupération (je suis plutôt curieux de le voir)...

1 votes

Essayez d'autres combinaisons de boutons telles que Power+Vol Up+Vol Down pour démarrer en mode Recovery. Si vous avez accès au ZIP du mode de récupération, il se peut qu'il y ait un fichier image du mode de récupération quelque part, que vous pouvez flasher à partir de fastboot ou démarrer directement dans ce mode ( fastboot boot <FILE>.img ), puis flashez le fichier ZIP complet du stock. Alternativement, voyez s'il existe (sur le web) les fichiers ROM stock qui peuvent être flashés en utilisant fastboot.

8voto

Adrian Pirvulescu Points 3671

Episode 3 : Le retour de la coquille.

Si je voulais avoir une chance de résoudre ce problème, je devais d'abord comprendre pourquoi le shell ne fonctionnait pas. adbd répondait lui-même, il a donc été lancé du côté de la tablette - mais il ne pouvait pas exécuter le shell, même lorsque je l'ai hacké pour invoquer un fichier ( /sbin/sh ) que j'ai moi-même placé dans l'image de démarrage - en étant sûr à 100% qu'il avait les permissions appropriées et qu'il était accessible à partir de la page d'accueil du site web de l'entreprise. shell (id=2000) compte que adbd utilise.

Ce qui ne laissait qu'une seule explication - les "cages" SELinux.

J'ai donc vérifié comment adbd a été lancé à partir de l'image de démarrage de mon 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 a 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 enfin pu accéder à la tablette - de "l'intérieur".

En vérifiant le /system monté, il est apparu clairement que le processus de flashage - bien que fastboot flash system ... a rapporté que tout était OK - avait échoué spectaculairement . C'était un miracle que la partition soit montée en premier lieu.

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

Je devais démarrer la tablette pour qu'elle utilise ma copie immaculée de la partition /system, mais à ce stade, même si j'avais un accès shell, je n'étais pas Root - ( les changements que j'ai faits dans default.prop sont apparemment ignorés par le noyau Asus - je vais devoir le recompiler bientôt... ), je n'ai donc pas pu monter la carte SD externe. dd sur ma bonne copie.

Mais j'avais ma propre image de démarrage - ce qui signifiait que je pouvais modifier les /fstab.qcom à l'intérieur, et faites ça :

La ligne originale qui dit à la tablette comment monter /system

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

Mon montage

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

...et de retour dans ma boîte linux, j'ai dd -J'ai transféré la sauvegarde impeccable de la partition système de la tablette sur la deuxième partition de ma carte SD externe, que j'ai créée par l'intermédiaire de gparted pour être exactement 2GB.

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

EDIT : Le voyage a continué - j'ai finalement J'ai patché et compilé mon propre noyau et je suis devenu Root. .

2 votes

Je jure à l'épisode 4, j'aurais offert une prime si cette réponse n'était pas postée, pour le plaisir de tous ces épisodes. C'est bien de voir que tu as résolu ton problème par toi-même. :D

2 votes

@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 le /system La partition est sur la carte SD, modifiable à souhait. C'est un peu comme démarrer un PC à partir d'une clé USB :-)

4voto

naki Points 171

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 ceci probablement aurait 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, est-ce que votre tablette a retourné un max-download-size variable ? Si c'était le cas, cela aurait pu constituer un avertissement, purement et simplement, que le processus de flashage pourrait avoir quelques problèmes avec une image aussi grande. Le code actuel de fastboot est fait pour fonctionner autour d'un max-download-size qui est trop petite, mais j'ai rencontré la même erreur même lorsque l'image est plus petite que ce que l'appareil dit pouvoir gérer, donc en fait le point est un peu discutable, 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 êtes incapable de flasher. Si vous et moi avons raison, et qu'il s'agit d'une question de taille (votre tablette n'a qu'1 Go de RAM, et En principe, la plupart des appareils essaient de lire l'image entière dans la mémoire vive avant de flasher. ), c'est là que je pense que le simple ajustement de l'ajout de l'option -S l'option de fastboot pourrait avoir réparé votre flash comme cela a été le cas pour moi :

fastboot -S 512M flash system system.img  

Au lieu de cela, il semble que vous ayez essayé de forcer votre image de 2 Go dans une taille qui (1) n'est peut-être pas possible pour elle et (2) n'est pas la taille que la partition système de votre appareil est censée avoir.

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

  • En ce qui concerne le point 2, je ne crois pas que vous puissiez faire ça tout simplement ; des étapes supplémentaires seraient nécessaires pour utiliser un système différent taille de partition.

En supposant que votre tablette s'attende à des fichiers image épars, je crois que la commande que vous vouliez essayer au lieu de make_ext4fs -l 1536M new_system.img /system était make_ext4fs -l 2048M -s new_system.img /system . La commande ajustée produirait une image qui se gonfle à la taille correcte, mais qui est stockée temporairement dépourvue de tout excès de graisse, comme de grandes poches de données vides : une " éparses fichier image" (voir la page dont j'ai donné le lien plus haut 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 readme que quelqu'un a écrit pour une collection d'outils devrait aider à comprendre comment se déroule le processus.

Salud.

1 votes

Merci de répondre. En ce qui concerne vos questions, (1) non, il n'y avait pas de max-download- rien dans la sortie de getvar . (2) Je garderai à l'esprit le -S dans mes futurs flashages - en fait, une fois que j'ai démarré, je suis devenu Root (via la recompilation de mon noyau) et je n'ai pas eu le temps de m'en servir. dd -sur l'ancienne partition système, donc si flasher avec -S fonctionne devra attendre mes prochains tests (3) J'ai essayé avec des images éparses, j'ai obtenu le même résultat (i.e. fastboot a signalé que le flashage était OK, mais que la partition du système était en désordre).

1 votes

@ttsiodras Pas de problème. J'ai appris certaines choses dans le processus. (1) Ah, d'accord. Je doutais que ce soit le cas, car 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, entre-temps, pour avoir démontré que all peut être passé à getvar - c'est utile). (2) Ohh, ok. Si ça marche, faites-le nous savoir. (3) Oups ! Je n'avais pas remarqué ça. Il y a beaucoup de texte, désolé. Est-ce que cela a été mentionné dans vos messages ? (Était-ce comme la commande make_ext4fs que j'ai suggérée, avec -s et la longueur totale de 2 GiB spécifiée ?) Peut-être que la tablette n'a pas traiter les fichiers épars.

1 votes

(3) oui, j'ai réussi -s pour make_ext4fs - fastboot a rapporté 'OK' pour la gravure, mais /system était en désordre. Ma théorie est que, comme vous l'avez dit, tout ce qui est plus grand que la mémoire de la tablette (1GB) ne fonctionnerait pas, et qu'il fallait l'option "make_ext4fs". -S dans fastboot pour qu'elle fonctionne correctement (ce qui explique l'état à moitié cassé - la partition a été montée parce que la première partie de l'image tenait dans la mémoire et était effectivement gravée, ce qui permettait de la monter - mais les fichiers à l'intérieur étaient... corrompus de façon aléatoire, selon que leurs secteurs étaient gravés ou non).

2voto

Metalx1000 Points 21

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

Regardez les vidéos que j'ai réalisées à ce sujet ici : https://youtu.be/BHCamV-sHx0?list=PLcUid3OP_4OVI1Rtuwxk1RjABh1PxXXQq

0 votes

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, j'y suis parvenu immédiatement sur ma MotoG2 - la récupération de cette tablette est donc défectueuse). Je peux flasher la partition de récupération (puisque flashboot est opérationnel) mais je n'ai aucun moyen d'y accéder. recovery.img d'Asus, et aucun CWM ou TWRP n'existe (pour un ME103K) non plus.

androidalle.com

AndroidAlle est une communauté de androiders où vous pouvez résoudre vos problèmes et vos doutes. Vous pouvez consulter les questions des autres sysadmins, poser vos propres questions ou résoudre celles des autres.

Powered by:

X