Der Versuch, ein system.img zu flashen, das ich mit dd aufgenommen habe - fehlgeschlagen
tsiodras
Langjähriger UNIX-Typ hier, aber relativ neu in der Android-Welt. Weiter lesen.
EPISODE 1: Ein neues Backup (hoffte ich)
Ich habe kürzlich ein Asus MemoPAD (ME103K) gekauft; Ich wurde dann root und nahm ein ddImage der schreibgeschützten systemPartition auf die externe SD-Karte:
$ 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
Etwas verdächtig war die Größe (exakt 2GiB) - kann das an der FAT32-Partition auf der SD-Karte liegen?
Nein, das war es nicht – es stellte sich tune2fs -lheraus, dass es sich tatsächlich um ein gültiges EXT4-Image mit genau 2 GiB handelte, das fsck -fohne Fehler bestanden wurde. Und fastboot(von der an das Tablet angeschlossenen Linux-Maschine) stimmte zu, nach einem 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
Diese Größe beträgt tatsächlich 2 GB:
linuxbox# python2 -c 'print 0x0000000080000000'
2147483648
Also, alles ist gut - ich habe eine Sicherungskopie des Bildes. Jetzt testen Sie die Wiederherstellung.
Ich versuche, das system.img zurück auf das Tablet zu flashen - um sicherzustellen, dass ich alles wiederherstellen kann, die Art von kugelsicherem Backup, das wir in der Unix-Welt machen ( zB Wiederherstellung des Inhalts eines Laufwerks überdd if=backup.image of=/dev/sdXXX ).
Alles rund adbund fastbootfunktioniert einwandfrei - also versuche ich...
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. Ich lade die meiner Distribution aus den Quellen herunter und erstelle android-tools-5.1.1sie, füge Debug-Informationen hinzu - und gehe in den Debugger, um diesen Fehler zu sehen:
linuxbox# gdb --args fastboot flash system system.img
...
Interessant - obwohl ich mich auf einem 64-Bit-Computer befinde, gibt es anscheinend Probleme, die die Dateigröße "negativ" machen (in einer 32-Bit-Welt wird die Dateigröße meines Bildes, 2 ^ 31, tatsächlich als negativ angesehen - um genau zu sein, -2147483648.
OK, gut - wie flashen sie große Bilddateien in Android?
Googeln, suchen - es stellt sich heraus, dass sie dieses make_ext4fsTool verwenden, das flashbare Bilder erstellt. Tatsächlich ist es Teil dessen, was ich gerade kompiliert habe, also könnte ich es genauso gut verwenden:
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 - also kann ich anscheinend Systemabbilder aus einfachen alten Ordnern erstellen. Der Himmel wird meine Grenze sein - ich kann diesem Bild alles hinzufügen, was ich will.
Lass es uns verbrennen...
linuxbox# fastboot flash system new_system.img
erasing 'system'...
OKAY [ 0.064s]
sending 'system' (2088960 KB)...
^C
Ich habe 1 Stunde gewartet, bevor ich Strg-C gedrückt habe. Und musste das Tablet aus- und wieder einschalten, das im Fastboot-Modus wieder hochgefahren wurde.
Das sieht nicht gut aus.
Was ist, wenn ich ein kleineres Image erstelle? Vielleicht sind die 2 GB irgendwie ein Problem, und diese Partition ist nicht voll ausgelastet - sie hat freien Speicherplatz:
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, das sieht sehr vielversprechend aus (und hat nur 5 min gedauert). Ich denke, ich kann jetzt neu starten und alles sollte normal sein, ja?
Nein :-)
Ich habe nichts gegen ein vorübergehend gemauertes Gerät, solange ich es am Ende steuern kann (Maschinen, die ich nicht beherrsche, sind Maschinen, die ich nicht bedienen möchte ;-)
Irgendwelche Ideen, was ich falsch gemacht habe und was ich tun kann, um das zu beheben?
Danke im Voraus.
PS Ich habe die Support-Seite von Asus für mein Tablet überprüft - sie bieten nur die Quellen für den Kernel und die Over-the-Air-.zip-Datei. Das wiederum enthält eine Sicherung auf Dateisystemebene aus dem Stammverzeichnis - dh der systemOrdner existiert darin nur als Ordner, nicht als Bild, nicht als ein system.img, das ich flashen kann - das hilft mir also nicht wirklich.
EPISODE 2: Angriff der Custom-Stiefel
In Ermangelung jeglicher Art recovery.imgvon Asus (warum sollte sich ein Hersteller die Mühe machen, ein Fastboot-Flashable zu veröffentlichen recovery.img? Warum eigentlich ...) und ein ähnliches Fehlen von Wiederherstellungs-Images von den CWM- und TWRP-Sites ... muss ich alles bekämpfen allein.
Zum Glück enthält die Over-the-Air-Update-Datei von Asus darin ...
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
...das Boot-Image meines Tablets. Nun, vielleicht – nur vielleicht – kann ich damit etwas anfangen.
linuxbox$ mkdir rootfs
linuxbox$ cd rootfs
linuxbox$ abootimg -x /path/to/boot.img
linuxbox$ ls -l
bootimg.cfg
initrd.img
zImage
Ramdisk erweitern...
linuxbox$ mkdir initrd
linuxbox$ cd initrd
linuxbox$ gzip -cd ../initrd.img | cpio -ivd
...
linuxbox$ vi default.prop
Ich richte mich ein default.prop, um root zu sein, wenn der Kernel bootet:
ro.secure=0
ro.debuggable=1
ro.adb.secure=0
androidboot.selinux=disabled
Ich habe auch /system/bin/sh( aus der Over-the-Air-Asus-.zip-Datei ) in /sbin/sh. Ich habe das gleiche mit busybox gemacht - ein ziemlich praktisches Tool.
Und die boot.img neu gepackt ...
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
abootimgBeim ersten Ausführen ist dies tatsächlich fehlgeschlagen, da bootimg.cfgaktualisiert werden musste - der bootsizeParameter musste geändert werden, da das Paket jetzt größer ist. abootimgmeldet, was es braucht, also ist das einfach genug.
Und jetzt starte ich mein benutzerdefiniertes Image ...
linuxbox# fastboot boot new_boot_busybox.img
...und bezeuge folgendes...
linuxbox# adb logcat
- exec '/system/bin/sh' failed: Permission denied (13) -
linuxbox# adb shell
- exec '/system/bin/sh' failed: Permission denied (13) -
Hmm ... Vielleicht wird adbd nicht als root ausgeführt?
linuxbox# adb root
restarting adbd as root
linuxbox# adb shell
- exec '/system/bin/sh' failed: Permission denied (13) -
Gut ... Ich habe adbd hexeditiert und /system/bin/sh auf /sbin/sh gepatcht (ich habe /system/bin/sh aus dem OTA-Image in die rootfs der initrd kopiert): Reboot, fastboot ...
linuxbox# adb shell
- exec '/sbin/sh' failed: Permission denied (13) -
Verflixt. Kann das Ding was?
linuxbox# adb pull /proc/partitions
15 KB/s (1272 bytes in 0.079s)
Es ist ... mal sehen:
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, also ist /system gemountet. Kann ich sehen, was drin ist?
linuxbox# adb pull /system
remote object '/system' does not exist
Was zum ... Vielleicht kann ich überprüfen, was /proc/kmsg enthält (was "dmesg" ausgeben würde)
linuxbox# adb pull /proc/kmsg
failed to copy '/proc/kmsg' to './kmsg': Operation not permitted
Nein, ich muss root sein, um das zu tun.
linuxbox# adb push /sbin/sh /system/bin/sh
failed to copy '/sbin/sh' to '/system/bin/sh': Permission denied
Und das auch.
Das entpuppt sich als ziemliches Rätsel...
Antworten (3)
tsiodras
Folge 3: Rückkehr der Muschel.
Wenn ich jemals eine Chance hatte, das zu lösen, musste ich zuerst herausfinden, warum die Shell nicht funktionierte. adbdselbst reagierte, also wurde es auf der Tablet-Seite gestartet - aber es konnte die Shell nicht ausführen, selbst wenn ich es hack-patchierte, um eine Datei ( /sbin/sh) aufzurufen, die ich selbst in das Boot-Image eingefügt hatte - da ich mir zu 100% sicher war, dass dies der Fall war die richtigen Berechtigungen und war über das shell(id=2000)-Konto zugänglich, das adbdverwendet wird.
Was nur eine Erklärung übrig ließ - SELinux "Käfige".
Also habe ich überprüft, wie adbdvon meinem Boot-Image gestartet wurde 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
...und versuchte eine offensichtliche Änderung:
service adbd /sbin/adbd
class core
socket adbd stream 660 system system
Ich packte wieder ein und sah zu meiner größten Befriedigung ...
linuxbox# adb shell
$
Endlich habe ich Zugriff auf das Tablet bekommen - von "innen".
Beim Überprüfen des gemounteten /systems wurde klar, dass der Flash-Vorgang – obwohl gemeldet wurde, dass alles in Ordnung war – spektakulärfastboot flash system ... fehlgeschlagen war . Es war ein Wunder, dass die Partition überhaupt gemountet wurde.
Das erklärte, warum das Tablet nicht startete, und gab mir die letzte Idee, die das Problem löste.
Ich musste das Tablet booten, damit es meine ursprüngliche Kopie der /system-Partition verwendet, aber zu diesem Zeitpunkt war ich, obwohl ich Shell-Zugriff hatte, nicht root - ( die Änderungen, die ich vorgenommen habe, default.propwerden anscheinend vom Asus-Kernel ignoriert - Ich muss es bald neu kompilieren ... ), daher konnte ich die externe SD-Karte nicht einhängen und ddüber meine gute Kopie.
Aber ich hatte mein eigenes Boot-Image - was bedeutete, dass ich das darin enthaltene bearbeiten /fstab.qcomund Folgendes tun konnte:
Ursprüngliche Zeile, die dem Tablet mitteilte, wie es /system mounten soll
/dev/block/platform/msm_sdcc.1/by-name/system /system ext4 ro,barrier=1 wait
Meine Bearbeitung
/dev/block/mmcblk1p2 /system ext4 rw,barrier=1 wait
... und zurück in meiner Linux-Box habe ich dddie ursprüngliche Sicherung der Systempartition des Tablets auf die zweite Partition meiner externen SD-Karte gesetzt - die ich über gpartedgenau 2 GB erstellt habe.
Das hat es getan - das Tablet hat von meiner externen SD-Karte gebootet.
EDIT : Die Reise ging weiter – schließlich habe ich meinen eigenen Kernel gepatcht und kompiliert und wurde root .
Feuerlord
tsiodras
fastboot boot ...) und die /systemPartition befindet sich auf der SD-Karte, die nach Belieben angepasst werden kann. So ähnlich wie das Booten eines PCs von einem USB-Stick :-)Naki
Es scheint, dass Sie bereits eine Art Lösung für Ihr Problem gefunden haben (auf dieser Seite gibt es viel Text zu lesen), aber es scheint, dass dies wahrscheinlich viel einfacher hätte gelöst werden können.
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
Hat Ihr Tablet unter diesen Variablen eine max-download-sizeVariable zurückgegeben? Wenn ja, könnte dies eine Warnung gewesen sein, dass der Flash-Prozess mit einem so großen Bild einige Probleme haben könnte. Der aktuelle Fastboot-Code wurde entwickelt, um einen max-download-sizezu kleinen Code zu umgehen, aber ich habe denselben Fehler erlebt, selbst wenn das Image kleiner ist als das, was das Gerät verarbeiten kann, also ist der Punkt eigentlich ziemlich strittig, denke ich.
linux_box# fastboot flash system system.img
error: cannot load 'system.img'
Wie auch immer, hier scheint es, dass Sie aus irgendeinem Grund nicht flashen können. Wenn Sie und ich Recht haben und es um die Größe geht (Ihr Tablet hat nur 1 GB RAM, und angeblich versuchen die meisten Geräte, das gesamte Bild vor dem Flashen in den RAM einzulesen-S ), ist dies meiner Meinung nach die einzige Anpassung, um die Option hinzuzufügen to fastboot hat möglicherweise Ihren Flash so repariert wie bei mir:
fastboot -S 512M flash system system.img
Stattdessen haben Sie jedoch anscheinend versucht, Ihr 2-GB-Image in eine Größe zu zwingen, die (1) möglicherweise nicht möglich ist, und (2) nicht die Größe hat, die die Systempartition Ihres Geräts haben sollte.
In Bezug auf Punkt 1 würde ich mich meiner Erfahrung nach nicht darauf verlassen, dass sich die spröden Android-Build-Tools beschweren, wenn Sie sie bitten, etwas zu tun, bei dem sie scheitern werden, und es ist möglich, dass sie es hier haben.
In Bezug auf Punkt 2 glaube ich nicht, dass Sie das nicht einfach tun können. zusätzliche Schritte wären erforderlich, um eine andere Systempartitionsgröße zu verwenden.
Angenommen, Ihr Tablet erwartet spärliche Bilddateien, ich glaube, der Befehl, den Sie anstelle von ausprobieren wollten, make_ext4fs -l 1536M new_system.img /systemwar make_ext4fs -l 2048M -s new_system.img /system. Der angepasste Befehl würde ein Bild erstellen, das sich auf die richtige Größe aufbläst, aber vorübergehend von überschüssigem Fett befreit wird, wie große Taschen mit leeren Daten: eine " sparse image file" (weitere Informationen dazu finden Sie auf der Seite, auf die ich zuvor verlinkt habe; Ich habe nicht genug Ruf auf dieser Seite, um den Link zu wiederholen).
Diese alte Readme-Datei, die jemand für eine Sammlung der Tools geschrieben hat, sollte helfen zu verstehen, wie der Prozess abläuft.
Prost.
tsiodras
max-download-in der Ausgabe von war nichts enthalten getvar. (2) Ich werde die -SOption bei meinen zukünftigen Flashs im Hinterkopf behalten - so wie es ist, wurde ich nach dem Booten root (durch Neukompilieren meines Kernels) und dd-ed über die alte Systempartition, also ob das Flashen mit -S funktionieren würde muss auf meine nächsten Tests warten (3) Ich habe es mit Sparse-Images versucht, habe das gleiche Ergebnis erhalten (dh fastbootgemeldet, dass das Flashen in Ordnung war, aber die Systempartition war durcheinander gebracht).Naki
allsie an getvar übergeben werden kann - das ist hilfreich). (2) Oh, okay. Wenn es funktioniert, lassen Sie es uns wissen. (3) Hoppla! Das ist mir nicht aufgefallen. Es ist viel Text, sorry. Wurde das in deinen Beiträgen erwähnt? (War es wie der von mir vorgeschlagene Befehl make_ext4fs, mit -sund der vollen Länge von 2 GiB angegeben?) Vielleicht kommt das Tablet nicht mit Dateien mit geringer Dichte zurecht.tsiodras
-shabe make_ext4fs übergeben - fastboot hat 'OK' zum Brennen gemeldet, aber /system war durcheinander. Meine Theorie ist, dass, wie Sie sagten, alles, was größer als der Speicher des Tablets (1 GB) ist, nicht funktionieren würde und die -SOption in Fastboot benötigt, um richtig zu funktionieren (was den halb kaputten Zustand erklärt - die Partition wurde gemountet, weil der erste Teil des Abbilds in den Speicher passte und tatsächlich gebrannt wurde, sodass es gemountet werden konnte - aber Dateien darin waren ... zufällig beschädigt, je nachdem, ob ihre Sektoren gebrannt wurden oder nicht).Metallx1000
Mit meinem Moto GI erstellte ich ein Backup mit dd wie Sie es getan haben. Ich musste neulich meine Systempartition wiederherstellen, also habe ich TWRP gebootet (ich habe es nicht geflasht, ich habe nur das Image in den RAM gebootet). Ich habe dann adb verwendet, um eine Verbindung herzustellen, während TWRP ausgeführt wurde, und ich habe einfach das img, das ich mit dd erstellt habe, auf meine SD-Karte geschoben und dann dd verwendet, um das Image auf die Systempartition zu schreiben.
Sehen Sie sich hier die Videos an, die ich darüber gemacht habe: https://youtu.be/BHCamV-sHx0?list=PLcUid3OP_4OVI1Rtuwxk1RjABh1PxXXQq
tsiodras
recovery.imgvon Asus, und es gibt auch kein CWM oder TWRP (für einen ME103K).Im Fastboot stecken?! Hilfe bitte!
Was passiert nach dem Unbricking eines Oneplus 3
Wie kann ich den Bootloader passieren (Huawei Y200 steckt Logo / Boot-Loop)
Weich gemauertes Moto G4 (XT1625) nach SuperSU-Installation
OnePlus 6T Hat "Fastboot Boot" gerade alle meine verschlüsselten Daten gelöscht?
Fastboot erkennt meinen LAVA Iris Atom nicht
HTC One M7 bleibt beim Booten hängen
Kann Android-Gerät mit ADB auf Mac nicht erkennen, kann es aber über Fastboot erkennen?
Stock Nexus 4 steckt im Bootloop fest
harter Ziegel? [Asus Zenfone 5 - Lutscher]
Feuerlord
tsiodras
fastbootes immer noch betriebsbereit ist (reagiert problemlos auf Anfragen) und ich daher jedes Wiederherstellungsimage brennen kann, (a) habe ich gesucht und kein CWM- oder TWRP-Wiederherstellungsimage für ME103K gefunden - ich nehme nicht an, dass es eines gibt eine "allgemeine", auf die Sie sich beziehen, gibt es? (b) Beim Ausschalten, Drücken des Netzschalters + Leiser wird das Wiederherstellungsabbild nicht angezeigt - ich komme immer noch nur in den Fastboot-Zustand. Ich weiß warum. Tatsächlich habe ich den Wiederherstellungsprozess nie gesehen (irgendwie neugierig, ihn zu sehen) ...Feuerlord
fastboot boot <FILE>.img), dann flashen Sie die gesamte Stock-ZIP-Datei. Alternativ können Sie prüfen, ob (im Internet) die Standard-ROM-Dateien vorhanden sind, die mit Fastboot geflasht werden können.tsiodras
unzip -l UL-K01E-WW-12.16.1.12-user.zip | grep recoveryzeigt nur ein paar Shell-Skripte - ich werde mal nachsehen, aber da ist definitiv keinsrecovery.img). Googeln hat auch nicht geholfen - es gibt nirgendwo Wiederherstellungsbilder dieses Tablets ... Muss ich wohl auf eine freundliche Seele warten, umddihre Wiederherstellungspartition zu teilen?