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 dd
image de la system
partition 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 -l
révélé qu'il s'agissait bien d'une image EXT4 valide, exactement à la taille de 2 Go, qui a réussi fsck -f
sans 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 adb
et fastboot
fonctionne 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.1
ma 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_ext4fs
outil, 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 system
dossier existe là-dedans comme juste un dossier, pas une image, pas une system.img
que 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.img
Asus (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.prop
pour ê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
abootimg
En fait, j'ai échoué la première fois que je lance ceci, car il bootimg.cfg
a dû être mis à jour - le bootsize
paramètre a dû être changé, car le package est plus gros 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 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 ...
la source
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 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) ...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.unzip -l UL-K01E-WW-12.16.1.12-user.zip | grep recovery
ne montre que quelques scripts shell - je vais y jeter un œil, mais il n'y en a certainement pasrecovery.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 pourdd
leur partition de récupération et la partager?Réponses:
É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.
adbd
lui-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 compteshell
(id = 2000) quiadbd
utilise.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émarrageinit.rc
:... et essayé un changement évident:
J'ai remballé, et à ma grande satisfaction, j'ai vu ...
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.prop
sont 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 etdd
sur ma bonne copie.Mais j'avais ma propre image de démarrage - ce qui signifiait que je pouvais modifier l'
/fstab.qcom
intérieur, et faire ceci:Ligne originale expliquant à la tablette comment monter / système
Ma rédaction
... et de retour dans ma boîte Linux, j'ai
dd
sauvegardé 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 viagparted
pour 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 .
la source
fastboot boot ...
) et la/system
partition est sur la carte SD, ajustable à tout ce que je veux. Un peu comme, démarrer un PC à partir d'une clé USB :-)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.
Parmi ces variables, votre tablette a-t-elle renvoyé une
max-download-size
variable? 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 codemax-download-size
trop 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.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'
-S
option fastboot pourrait avoir corrigé votre flash comme il l'a fait pour moi: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
étaitmake_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é.
la source
max-download-
rien dans la sortie degetvar
. (2) Je garderai à l'esprit l'-S
option 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) etdd
-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-à-direfastboot
que le flash était correct, mais la partition système était foirée).all
peut ê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-s
la longueur complète de 2 Gio spécifiée?) Peut-être que la tablette ne gère pas les fichiers épars.-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'-S
option 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).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
la source
recovery.img
d'Asus, et il n'y a pas non plus de CWM ou TWRP (pour un ME103K).