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

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
...

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 :-)

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/sh(à partir 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 ...

É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 .

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é.

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