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
...
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 :-)
Ç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.1 votes
@Firelord : Non, Asus ne fournit pas de recovery.zip. A partir du fichier OTA, il n'y a rien de .img-y (
unzip -l UL-K01E-WW-12.16.1.12-user.zip | grep recovery
ne montre que quelques scripts shell - je vais regarder, mais il n'y a certainement pas derecovery.img
là). 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... J'imagine que je vais devoir attendre qu'une âme charitable mette en place un système de récupération.dd
leur partition de récupération et de partage ?