Ich habe versucht, ein system.img zu flashen, das ich mit dd - failing aufgenommen habe

Langjähriger UNIX-Typ hier, aber relativ neu in der Welt von Android. Weiter lesen.

EPISODE 1: Ein neues Backup (ich hoffte)

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

Die Größe (genau 2 GB) war ein bisschen verdächtig - kann es sein, dass dies an der FAT32-Partition auf der SD-Karte lag?

Nein, es wurde nicht tune2fs -lfestgestellt, dass es sich in der Tat um ein gültiges EXT4-Image mit einer Größe von 2 GB handelte, das überhaupt fsck -fnicht fehlerfrei verlief . Und fastboot(von der Linux-Maschine, die an das Tablet angeschlossen ist) stimmte 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 in der Tat 2 GB:

linuxbox# python2 -c 'print 0x0000000080000000'
2147483648

Alles ist gut - ich habe eine Sicherungskopie des Bildes. Jetzt testen Sie die Wiederherstellung.

Ich versuche, die Datei system.img auf das Tablet zurückzuspielen - um sicherzustellen, dass ich von allem, was wir in der Unix-Welt machen, eine kugelsichere Sicherung erstellen kann ( z. B. den Inhalt eines Laufwerks über wiederherstellendd if=backup.image of=/dev/sdXXX ).

Alles rund um 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 android-tools-5.1.1meine Distribution aus den Quellen herunter und erstelle sie , indem ich Debug-Informationen hinzufüge - und gehe dann im Debugger vor, um diesen Fehler zu sehen:

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

Interessant - obwohl ich in einer 64 - Bit - Maschine bin, offenbar gibt es Probleme, die die Dateigröße „negativ“ (in einer 32 - Bit - Welt, die Dateigröße meines Bildes drehen, 2 ^ 31, ist in der Tat negativ betrachtet - genau zu sein -2147483648.

OK, gut - wie flashen sie große Bilddateien in Android?

Googeln, suchen - es stellt sich heraus make_ext4fs, dass sie dieses Tool 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 - so kann ich anscheinend Systemimages 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, was im Fastboot-Modus zurücklief.

Das sieht nicht gut aus.

Was ist, wenn ich ein kleineres Image aufbaue? Vielleicht sind die 2 GB 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 Minuten gedauert). Ich schätze, ich kann jetzt wieder neu starten und alles sollte normal sein, ja?

Nein :-)

Ich habe nichts dagegen nicht vorübergehend gemauert Gerät, solange ich kann es an die Kontrolle am Ende (Maschinen , dass ich nicht ein Meister der Maschinen sind mir egal, zu arbeiten ;-)

Irgendwelche Ideen, was ich falsch gemacht habe und was ich tun kann, um das zu beheben?

Danke im Voraus.

PS: Ich habe die Asus-Support-Seite für mein Tablet überprüft. Sie enthält 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 ist dort nur als Ordner vorhanden, nicht als Image, nicht als system.imgFlash, was mir also nicht wirklich hilft.

EPISODE 2: Angriff der Custom Boots

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 in der Tat ...) und einer ähnlichen Abwesenheit bei Wiederherstellungsimages von den CWM- und TWRP-Sites ... bin ich allen überlassen allein.

Zum Glück enthält die Over-the-Air-Update-Datei von Asus ...

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 Startbild meines Tablets. Jetzt kann ich vielleicht - nur vielleicht - etwas damit anfangen.

linuxbox$ mkdir rootfs
linuxbox$ cd rootfs
linuxbox$ abootimg -x /path/to/boot.img
linuxbox$ ls -l
bootimg.cfg
initrd.img
zImage

Erweitern der Ramdisk ...

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

Ich habe mich default.propals root eingerichtet, 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 drahtlosen .zip-Datei von Asus ) in kopiert /sbin/sh. Ich habe dasselbe 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 Start ist dies tatsächlich fehlgeschlagen, da bootimg.cfgaktualisiert werden musste - der bootsizeParameter musste geändert werden, da das Paket jetzt größer ist. abootimgberichtet, was es braucht, das ist also einfach genug.

Und jetzt starte ich mein benutzerdefiniertes Image ...

linuxbox# fastboot boot new_boot_busybox.img

... und bezeugen Sie 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) -

Fein ... ich hexedit adbd und patch / system / bin / sh zu / sbin / sh (ich kopierte das / system / bin / sh aus dem OTA-Image in die Rootfs der initrd): Reboot, fastboot ...

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

Verflixt. Ist das Ding in der Lage, etwas zu tun?

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 / system ist 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 wird ein ziemliches Rätsel ...

Episode 3: Rückkehr der Shell.

Wenn ich jemals eine Chance hatte, dies zu lösen, musste ich zuerst herausfinden, warum die Shell nicht funktionierte. adbdselbst reagierte, also wurde es auf der Tablettseite gestartet - aber es konnte die Shell nicht ausführen, selbst wenn ich sie mit einem Hack-Patch gepatcht habe, um eine Datei ( /sbin/sh) aufzurufen , die ich selbst in das Boot-Image eingefügt habe die richtigen Berechtigungen und war über shelldas adbdverwendete Konto (id = 2000) zugänglich .

Was nur eine Erklärung übrig ließ - SELinux "Käfige".

Also überprüfte ich, 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 um und sah zu meiner großen Zufriedenheit ...

linuxbox# adb shell
$ 

Endlich habe ich Zugriff auf das Tablet - von "innen".

Bei der Überprüfung des gemounteten Systems wurde deutlich, dass der Flash-Vorgang - obwohl fastboot flash system ...gemeldet wurde, dass alles in Ordnung war - spektakulär fehlgeschlagen war . Es war ein Wunder, dass die Partition an erster Stelle montiert wurde.

Das erklärte, warum das Tablet nicht bootete und gab mir die endgültige Idee, die das Problem löste.

Ich musste das Tablet booten, damit es meine makellose Kopie der / system-Partition verwendete, aber zu diesem Zeitpunkt war ich, obwohl ich über Shell-Zugriff verfügte, kein Root-Benutzer ( die Änderungen, die ich vorgenommen habe, default.propwerden vom Asus-Kernel anscheinend ignoriert). Ich muss es bald neu kompilieren ... ), damit ich die externe SD-Karte nicht ddüber meine gute Kopie mounten konnte .

Aber ich hatte mein eigenes Boot-Image - was bedeutete, dass ich das /fstab.qcomInnere des Images bearbeiten und dies tun konnte:

Ursprüngliche Zeile, in der dem Tablet mitgeteilt wurde, wie das System zu montieren ist

/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 makellose Sicherung der Systempartition des Tablets auf die zweite Partition meiner externen SD-Karte kopiert - die ich gpartedmit genau 2 GB erstellt habe.

Das Tablet wurde von meiner externen SD-Karte gebootet.

EDIT : Die Reise ging weiter - ich habe schließlich meinen eigenen Kernel gepatcht und kompiliert und bin root geworden .

Anscheinend haben Sie bereits eine Lösung für Ihr Problem gefunden (es gibt viel Text auf dieser Seite zu lesen), aber anscheinend hätte dies möglicherweise viel einfacher 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? In diesem Fall wurde möglicherweise eine Warnung ausgegeben, dass der Flash-Vorgang möglicherweise Probleme mit einem so großen Bild hat. Der aktuelle Fastboot-Code wurde erstellt, um ein Problem zu umgehen max-download-size, das zu klein ist, aber ich habe denselben Fehler auch dann festgestellt, wenn das Image kleiner ist als das, was das Gerät für möglich hält.

linux_box# fastboot flash system system.img  
error: cannot load 'system.img'

Es scheint also so, als ob Sie aus irgendeinem Grund nicht in der Lage sind, zu blinken. 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 Image vor dem Flashen in den RAM zu lesen ), dann ist dies meiner Meinung nach die bloße Anpassung des Hinzufügens der -SOption beim fastbooten könnte dein flash so repariert haben wie bei mir:

fastboot -S 512M flash system system.img  

Stattdessen haben Sie anscheinend versucht, Ihr 2-GB-Image auf eine Größe zu zwingen, in die (1) es möglicherweise nicht eingefügt werden kann, und (2) entspricht nicht der Größe, die die Systempartition Ihres Geräts haben soll.

• In Bezug auf Punkt 1 würde ich meiner Erfahrung nach nicht auf die spröden Android-Build-Tools zählen, um mich zu beschweren, wenn Sie sie bitten, etwas zu tun, an dem sie scheitern, und es ist möglich, dass sie hier etwas haben.

• In Bezug auf Punkt 2 glaube ich nicht, dass Sie das einfach nicht tun können. Zusätzliche Schritte wären erforderlich, um eine andere Systempartitionsgröße zu verwenden.

Unter der Annahme , dem Tablet erwartet Sparse - Image - Dateien, ich glaube , der Befehl , den Sie statt versuchen wollte make_ext4fs -l 1536M new_system.img /systemwar make_ext4fs -l 2048M -s new_system.img /system. Der eingestellte Befehl würde ein Bild machen , dass ich aufbläst auf die richtige Größe, sondern wird vorübergehend von überschüssigem Fett wie große Taschen von leeren Daten gestrippt gespeichert: eine „ Sparse - Image - Datei“ (siehe Seite I für weitere Informationen auf sie früher verbunden ist ; Ich habe nicht genug Ruf auf dieser Seite, um den Link zu wiederholen.

Diese alte Readme-Datei, die jemand für eine Sammlung von Tools geschrieben hat, soll helfen, den Ablauf zu verstehen.

Prost.

Mit meinem Moto GI habe ich mit dd ein Backup erstellt, wie du es getan hast. Ich musste neulich meine Systempartition wiederherstellen, also habe ich TWRP gebootet (ich habe es nicht geflasht, sondern 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 das mit dd erstellte Bild einfach auf meine SD-Karte verschoben und dann dd verwendet, um das Image auf die Systempartition zu schreiben.

Schauen Sie sich die Videos an, die ich dazu hier gemacht habe: https://youtu.be/BHCamV-sHx0?list=PLcUid3OP_4OVI1Rtuwxk1RjABh1PxXXQq