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 dd
Image der schreibgeschützten system
Partition 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 -l
festgestellt, dass es sich in der Tat um ein gültiges EXT4-Image mit einer Größe von 2 GB handelte, das überhaupt fsck -f
nicht 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 adb
und fastboot
funktioniert 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.1
meine 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 system
Ordner ist dort nur als Ordner vorhanden, nicht als Image, nicht als system.img
Flash, was mir also nicht wirklich hilft.
EPISODE 2: Angriff der Custom Boots
In Ermangelung jeglicher Art recovery.img
von 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.prop
als 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
abootimg
Beim ersten Start ist dies tatsächlich fehlgeschlagen, da bootimg.cfg
aktualisiert werden musste - der bootsize
Parameter musste geändert werden, da das Paket jetzt größer ist. abootimg
berichtet, 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 ...
quelle
fastboot
noch in Betrieb ist (auf Anfragen reagiert sie einwandfrei ) und ich daher jedes Wiederherstellungsimage brennen kann. (A) Ich habe nach ME103K gesucht und kein CWM- oder TWRP-Wiederherstellungsimage gefunden Eine "generische", auf die Sie sich beziehen, gibt es? (b) Beim Ausschalten, Drücken der Ein / Aus-Taste und Verringern der Lautstärke wird das Wiederherstellungs-Image nicht aufgerufen. Ich komme immer noch zum Fastboot-Status. Meine Idee warum. Tatsächlich habe ich den Wiederherstellungsprozess noch nie gesehen (irgendwie neugierig darauf) ...fastboot boot <FILE>.img
) aus flashen können , und dann die gesamte Stock-ZIP-Datei. Überprüfen Sie alternativ, ob die Standard-ROM-Dateien (im Internet) vorhanden sind, die mit Fastboot geflasht werden können.unzip -l UL-K01E-WW-12.16.1.12-user.zip | grep recovery
zeigt nur ein paar Shell-Skripte - ich werde es mir ansehen, aber es gibt definitiv keinerecovery.img
). Googeln hat auch nicht geholfen - es gibt nirgendwo ein Wiederherstellungs-Image dieses Tablets ... Vermutlich muss ich auf eine Art Seele warten, umdd
ihre Wiederherstellungs-Partition zu öffnen und zu teilen?Antworten:
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.
adbd
selbst 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 übershell
dasadbd
verwendete Konto (id = 2000) zugänglich .Was nur eine Erklärung übrig ließ - SELinux "Käfige".
Also überprüfte ich, wie
adbd
von meinem Boot-Image gestartet wurdeinit.rc
:... und versuchte eine offensichtliche Änderung:
Ich packte um und sah zu meiner großen Zufriedenheit ...
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.prop
werden vom Asus-Kernel anscheinend ignoriert). Ich muss es bald neu kompilieren ... ), damit ich die externe SD-Karte nichtdd
über meine gute Kopie mounten konnte .Aber ich hatte mein eigenes Boot-Image - was bedeutete, dass ich das
/fstab.qcom
Innere des Images bearbeiten und dies tun konnte:Ursprüngliche Zeile, in der dem Tablet mitgeteilt wurde, wie das System zu montieren ist
Meine Bearbeitung
... und zurück in meiner Linux-Box habe ich
dd
die makellose Sicherung der Systempartition des Tablets auf die zweite Partition meiner externen SD-Karte kopiert - die ichgparted
mit 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 .
quelle
fastboot boot ...
) und die/system
Partition befindet sich auf der SD-Karte und kann nach Belieben angepasst werden. So ähnlich wie das Booten eines PCs von einem USB-Stick :-)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.
Hat Ihr Tablet unter diesen Variablen eine
max-download-size
Variable 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 umgehenmax-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.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
-S
Option beim fastbooten könnte dein flash so repariert haben wie bei mir: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 /system
warmake_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.
quelle
max-download-
in der Ausgabe von war nichts enthaltengetvar
. (2) Ich werde die-S
Option in meinen zukünftigen Flashings berücksichtigen - so wie es ist, wurde ich nach dem Booten root (durch erneutes Kompilieren meines Kernels) unddd
-ed über die alte Systempartition, also ob das Flashen mit -S funktionieren würde Ich muss auf meine nächsten Tests warten. (3) Ich habe es mit spärlichen Images versucht, habe das gleiche Ergebnisfastboot
erzielt (dh das Flashen war in Ordnung, aber die Systempartition war durcheinander).all
getvar übergeben werden kann - das ist hilfreich). (2) Ohh, okay. Wenn es funktioniert, lass es uns wissen. (3) Hoppla! Das habe ich nicht bemerkt. Es ist viel Text, sorry. Wurde das in deinen Posts erwähnt? (War es wie der Befehl make_ext4fs, den ich vorgeschlagen habe, wobei-s
die volle Länge von 2 GB angegeben wurde?) Vielleicht kann das Tablet keine spärlichen Dateien verarbeiten.-s
habe 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 Arbeitsspeicher des Tablets (1 GB) ist, nicht funktionieren würde und die-S
Option in Fastboot benötigt, um richtig zu funktionieren (was den halb kaputten Zustand erklärt - die Partition wurde gemountet, weil der erste Teil Das Image passt in den Speicher und wurde tatsächlich gebrannt, sodass es gemountet werden konnte. Die darin enthaltenen Dateien wurden jedoch ... zufällig beschädigt, je nachdem, ob ihre Sektoren gebrannt wurden oder nicht.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
quelle
recovery.img
von Asus und auch keine CWM oder TWRP (für ein ME103K).