Vraag:
Ik probeerde een system.img te flashen die ik nam met dd - mislukt
ttsiodras
2015-09-27 18:31:33 UTC
view on stackexchange narkive permalink

Oude UNIX-man hier, maar relatief nieuw in de wereld van Android. Lees verder.

AFLEVERING 1: Een nieuwe back-up (hoopte ik)

Ik heb onlangs een Asus MemoPAD (ME103K) gekocht; Ik werd toen root en nam een ​​ dd -afbeelding van de alleen-lezen systeem -partitie naar de externe SD-kaart: 

  $ 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 27 september 13:15 system.img

De grootte (precies 2GiB) was een beetje verdacht - zou het kunnen zijn dat dit kwam door de FAT32-partitie op de SD-kaart?

Nee, dat was het niet - tune2fs -l onthulde dat dit inderdaad een geldige EXT4-afbeelding was, exact formaat 2GiB, die fsck passeerde - f zonder fouten. en fastboot (van de linux-machine die aan de tablet is gekoppeld) was het eens, na een adb reboot bootloader : 

  linuxbox # fastboot getvar alle (bootloader) versie-bootloader: 3.03 (bootloader) versie-hardware: rev_c (bootloader) variant: LEOPARDCAT 16G (bootloader) versie-basisband: H00_0.16.F_0521 (bootloader) serieel no: 0a3dXXXX ... (bootloader) partitietype: systeem: ext4 (bootloader) partitiegrootte: systeem: 0x0000000080000000

Die grootte is inderdaad 2GB: 

  linuxbox # python2 -c 'print 0x0000000080000000'2147483648

Dus alles is goed - ik heb een back-up van de afbeelding. Nu om het herstellen ervan te testen.

Ik probeer de system.img terug te flashen naar de tablet - om er zeker van te zijn dat ik alles kan herstellen, het soort kogelvrije back-up die we in de Unix-wereld doen ( bijv. herstel inhoud van een schijf via dd if = backup.image of = / dev / sdXXX ).

Alles met betrekking tot adb en fastboot werkt probleemloos - dus ik probeer ... 

  linux_box # fastboot devices0a3dXXXX fastbootlinux_box # mount / dev / sdcard / mnt / sdcard
linux_box # cp /mnt/sdcard/system.img .linux_box # fastboot flash system system.imgerror: kan 'system.img'

Hmm. Ik download en bouw de android-tools-5.1.1 van mijn distributie uit bronnen, waarbij ik foutopsporingsinformatie toevoeg - en stap in de debugger om deze fout te zien: 

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

Failure due to negative size!

Interessant - ook al ben ik in een 64-bits machine, zijn er blijkbaar problemen die de bestandsgrootte "negatief" maken (in een 32-bits wereld wordt de bestandsgrootte van mijn afbeelding, 2 ^ 31, inderdaad als negatief beschouwd - om precies te zijn, -2147483648 .

OK, prima - hoe flashen ze grote afbeeldingsbestanden in Android?

Googelen, zoeken - blijkt dat ze deze make_ext4fs tool gebruiken, die maakt flitsende afbeeldingen. In feite maakt het deel uit van wat ik zojuist heb gecompileerd, dus ik kan het net zo goed gebruiken: 

  linuxbox # mkdir / systemlinuxbox # mount -o loop, ro system.img / systemlinuxbox # ls -l / systemtotal 208drwxr-xr-x 106 root root 8192 17 september 22:24 appdrwxr-xr-x 3 root 2000 8192 26 september 21:08 bin-rw-r - r-- 1 root root 6847 S ep 12 16:59 build.propdrwxr-xr-x 19 root root 4096 26 sep 21:08 etcdrwxr-xr-x 2 root root 4096 11 aug 22:27 fontsdrwxr-xr-x 4 root root 4096 12 sep 16:56 frameworkdrwxr -xr-x 10 root root 16384 12 september 16:59 libdrwxr-xr-x 2 root root 4096 1 januari 1970 verloren + gevonden drwxr-xr-x 3 root root 4096 11 aug 22:18 mediadrwxr-xr-x 59 root root 4096 11 aug. 22:29 priv-app-rw-r - r-- 1 root root 126951 1 aug. 2008 recovery-from-boot.pdrwxr-xr-x 3 root root 4096 aug. 11 21:02 scriptsdrwxr-xr-x 3 root root 4096 aug 11 21:02 ttsdrwxr-xr-x 11 root root 4096 sep 26 21:08 usrdrwxr-xr-x 8 root 2000 4096 aug 11 22:29 vendordrwxr-xr-x 2 root 2000 4096 26 sep 21:09 xbinlinuxbox # ../extras/source/extras/ext4_utils/make_ext4fs \ -l 2048M new_system.img / system Bestandssysteem aanmaken met parameters: Grootte: 2147483648 Blokgrootte: 4096
Blokken per groep: 32768 Inodes per groep: 8192 Inodegrootte: 256 Journaalblokken: 8192 Label: Blokken: 524288 Blokgroepen: 16 Gereserveerde blokgroepgrootte: 127 Gemaakt bestandssysteem met 2666/131072 inodes en 375014/524288 blokken

Cool - dus ik kan blijkbaar systeemafbeeldingen maken van gewone oude mappen. De lucht zal mijn limiet zijn - ik kan alles wat ik wil aan deze afbeelding toevoegen.

Laten we het branden ... 

  linuxbox # fastboot flash-systeem nieuw_system.imgerasing 'systeem' ... OKAY [0.064s] verzenden van 'systeem' (2088960 KB) ... ^ C

Ik heb 1 uur gewacht voordat ik op Ctrl-C drukte. En moest de tablet uit en weer opstarten, die weer opstartte in de fastboot-modus.

Dit ziet er niet goed uit.

Wat als ik een kleinere afbeelding maak? Misschien zijn de 2GB op de een of andere manier een probleem, en wordt deze partitie niet volledig benut - er is vrije ruimte in: 

  linuxbox # ../extras/source/extras/ext4_utils/make_ext4fs \ -l 1536M new_system.img / systemlinuxbox # ./fastboot flash system system.img wissen van 'systeem' ... OKAY [0.065s] verzenden van 'systeem' (1572864 KB) ... OKAY [51.039s] schrijven 'systeem' ... OKAY [235.080s] klaar. totale tijd: 286.183s

OK, dit ziet er veelbelovend uit (en duurde slechts 5 minuten). Ik denk dat ik nu opnieuw kan opstarten en dat alles normaal zou moeten zijn, ja?

Nee :-)

enter image description here

Ik vind een tijdelijk dichtgemetseld apparaat niet erg, zolang ik het maar wel krijg om het uiteindelijk te bedienen (machines waar ik geen meester van ben, zijn machines die ik niet wil bedienen; - )

Ideeën over wat ik verkeerd heb gedaan en wat ik kan doen om dit op te lossen?

Bij voorbaat dank.

PS Ik heb de ondersteuningspagina van Asus voor mijn tablet gecontroleerd - ze bieden alleen de bronnen voor de kernel en het Over-the-air .zip-bestand. Dat bevat op zijn beurt een back-up op bestandssysteemniveau vanaf de root - dwz de map system bestaat daarin als slechts een map, geen afbeelding, niet een system.img die Ik kan flitsen - dus dat helpt me niet echt.

EPISODE 2: Attack of the Custom Boots

In de afwezigheid van enige vorm van recovery.img van Asus (waarom zou een fabrikant om een ​​fastboot-flashable recovery.img te publiceren? Waarom inderdaad ...) en een vergelijkbare afwezigheid op herstelafbeeldingen van de CWM- en TWRP-sites ... Ik moet helemaal alleen vechten.

Gelukkig bevat het over-the-air updatebestand van Asus erin ... 

  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

... de opstartimage van mijn tablet. Nu misschien - heel misschien - kan ik hier iets mee doen. 

  linuxbox $ mkdir rootfslinuxbox $ cd rootfslinuxbox $ abootimg -x /path/to/boot.imglinuxbox$ ls -lbootimg.cfginitrd.imgzImage

De ramdisk uitbreiden ... 

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

Ik heb default.prop ingesteld als root wanneer de kernel opstart: 

  ro.secure = 0ro.debuggable = 1ro.adb.secure = 0androidboot.selinux = uitgeschakeld

Ik heb ook / system / bin / sh gekopieerd ( uit het over-the-air Asus .zip-bestand ) naar / sbin / sh . Ik deed hetzelfde met busybox - best handig hulpmiddel.

En pakte de boot.img opnieuw in ... 

  busybox $ find. | cpio --create --format = 'newc' | gzip -9 > ../initrd.custom.gzbusybox$ cd ..busybox $ abootimg --create ../new_boot_busybox.img \ -f bootimg.cfg -k zImage -r initrd.custom.gz

abootimg mislukte de eerste keer dat ik dit startte, aangezien bootimg.cfg moest worden bijgewerkt - de bootize -parameter moest worden veranderd, aangezien het pakket nu groter is. abootimg rapporteert wat het nodig heeft, dus dat is eenvoudig genoeg.

En nu start ik mijn aangepaste afbeelding op ... 

  linuxbox # fastboot boot new_boot_busybox.img

... en wees getuige van het volgende ... 

  linuxbox # adb logcat- exec '/ system / bin / sh' mislukt: toestemming geweigerd (13) -linuxbox # adb shell- exec '/ system / bin / sh' mislukt: toestemming geweigerd (13) -

Hmm ... Misschien wordt adbd niet als root uitgevoerd? 

  linuxbox # adb rootrestarting adbd als rootlinuxbox # adb shell- exec '/ system / bin / sh' mislukt: toestemming geweigerd (13) -

Prima ... ik hexedit adbd, en patch / system / bin / sh te zijn / sbin / sh (ik heb de / system / bin / sh van de OTA-afbeelding naar de rootfs van het initrd gekopieerd): Reboot, fastboot ... 

  linuxbox # adb shell- exec '/ sbin / sh' mislukt: toestemming geweigerd (13) -

Verdorie. Is dit ding in staat om iets te doen? 

  linuxbox # adb pull / proc / partitions15 KB / s (1272 bytes in 0.079s)

Het is. .. eens kijken: 

  linuxbox # adb pull / proc / mounts16 KB / s (1358 bytes in 0.079s) linuxbox # grep systeem mounts / dev / block / platform / msm_sdcc.1 / door -name / system / system ext4 rw, seclabel, relatime, data = besteld 0 0

OK, dus / system is aangekoppeld. Kan ik zien wat erin zit? 

  linuxbox # adb pull / systemremote object '/ system' bestaat niet

Wat de ... Misschien kan ik het controleren wat / proc / kmsg bevat (wat "dmesg" zou uitvoeren) 

  linuxbox # adb pull / proc / kmsg kan '/ proc / kmsg' niet kopiëren naar './kmsg': Bewerking niet toegestaan

Nee, ik moet root zijn om dat te doen. 

  linuxbox # adb push / sbin / sh / system / bin / shfailed to copy '/ sbin / sh 'to' / system / bin / sh ': Toestemming geweigerd

En dat ook.

Dit blijkt een behoorlijke puzzel te zijn .. .

Het enige goede dat je hier niet hebt gedaan (en had moeten doen) is om een ​​aangepast herstel te flashen en vervolgens een [tag: nandroid] back-up te maken van de partities ervan. Dat is een van de kogelvrije methoden die er zijn om apparaten uit zo'n dichtgemetselde staat te herstellen. Die Over-the-air.zip (OTA-zip) is een flashable zip voor herstel, d.w.z. die moet worden geflitst wanneer ze worden opgestart in Recovery en ze volgen een ander verpakkingsformaat, maar bereiken hetzelfde doel. Om een ​​lang verhaal kort te maken, flash een aangepast herstel (of start het op in een standaard), flash het voorraad-ROM en experimenteer vervolgens zo veel als je wilt.
@Firelord: Dat is het ding - ook al is `fastboot` nog steeds operationeel (reageert prima op verzoeken) en ik kan daarom elk herstelimage branden, (a) ik heb gezocht en geen CWM- of TWRP-herstelimage voor ME103K gevonden - denk ik niet er is een "generiek" waarnaar u verwijst, nietwaar? (b) Uitschakelen, het indrukken van de aan / uit-knop + volume omlaag brengt de herstelimage niet naar voren - ik kom nog steeds in de fastboot-status. Mo idee waarom. In feite heb ik het herstelproces nog nooit gezien (nogal nieuwsgierig om het te zien) ...
Probeer andere knopcombinaties zoals Power + Vol Up + Vol Down om op te starten in de herstelmodus. Als je toegang hebt tot stock Recovery ZIP, dan kan er ergens het image-bestand van Stock Recovery zijn dat je kunt flashen vanuit fastboot of direct erin kunt opstarten (`fastboot boot .img`), en dan de hele stock ZIP flashen het dossier. U kunt ook kijken of er (op internet) de stock-ROM-bestanden bestaan ​​die kunnen worden geflitst met fastboot.
@Firelord: Nee, Asus biedt geen recovery.zip. Van het OTA-bestand is er niets .img-y (`unzip -l UL-K01E-WW-12.16.1.12-user.zip | grep recovery` toont slechts een paar shellscripts - ik zal eens kijken, maar er is zeker geen `recovery.img` daar). Googelen hielp ook niet - er zijn nergens herstelafbeeldingen van deze tablet ... Denk je dat ik zal moeten wachten tot een vriendelijke ziel hun herstelpartitie 'dd' en deelt?
Drie antwoorden:
ttsiodras
2015-09-30 12:25:17 UTC
view on stackexchange narkive permalink

Aflevering 3: Return of the Shell.

Als ik ooit de kans had dit op te lossen, moest ik eerst uitzoeken waarom de shell niet werkte. adbd zelf reageerde, dus het werd aan de tabletkant gestart - maar het kon de shell niet uitvoeren, zelfs niet toen ik het hackte om een ​​bestand op te roepen ( / sbin / sh ) die ik zelf in de opstartinstallatiekopie heb geplaatst - 100% zeker zijn dat deze de juiste rechten had en toegankelijk was vanuit de shell (id = 2000) -account die adbd toepassingen.

Wat slechts één uitleg overbleef - SELinux "cages".

Dus ik controleerde hoe adbd werd gestart vanaf mijn bootimage's init.rc : 

  # adbd wordt bestuurd via eigenschapstriggers in init.<platform>.usb.rcservice adbd / sbin / adbd --root_seclabel = u: r: su: s0 class core socket adbd stream 660 systeemsysteem heeft seclabel u: r: adbd: s0

... uitgeschakeld en een voor de hand liggende wijziging geprobeerd: 

  service adbd / sbin / adbd class core socket adbd stream 660 systeemsysteem

Ik herpakte, en tot mijn grote tevredenheid, zag ... 

  linuxbox # adb shell $

Ik kreeg eindelijk toegang tot de tablet - van "binnen".

Door het aangekoppelde / systeem te controleren, werd het duidelijk dat het knipperende proces - hoewel fastboot flash-systeem ... meldde dat alles in orde was - spectaculair was mislukt. Het was een wonder dat de partitie in de eerste plaats was aangekoppeld.

Dat verklaarde waarom de tablet niet opstartte en gaf me het laatste idee dat het probleem oploste.

Ik had het nodig om de tablet op te starten zodat het mijn oorspronkelijke kopie van de / systeempartitie gebruikte, maar op dit punt, hoewel ik shell-toegang had, was ik geen root - ( de wijzigingen die ik heb aangebracht in default.prop worden blijkbaar genegeerd door de Asus-kernel - ik zal het binnenkort opnieuw moeten compileren ... ) zodat ik de externe sdcard en dd niet over mijn goede kopie kon mounten.

Maar ik had wel mijn eigen opstartimage - wat betekende dat ik de /fstab.qcom erin kon bewerken, en dit kon doen:

Originele regel die vertelde de tablet hoe /system

/dev/block/platform/msm_sdcc.1/by-name/system / system ext4 ro, barrier = 1 wait

Mijn bewerking 

  / dev / block / mmcblk1p2 / system ext4 rw, barrier = 1 wait

... en terug in mijn linux-box, ik dd -ed de ongerepte back-up van de tablet-systeempartitie naar de 2e partitie van mijn externe SD-kaart - die ik heb gemaakt via gparted om precies 2 GB te zijn.

Dat deed het - de tablet startte op vanaf mijn externe SD-kaart.

BEWERKEN : de reis ging verder - ik herstelde en compileerde mijn eigen kernel en werd root.

Ik zweer bij aflevering 4, ik zou een premie hebben aangeboden als dit antwoord niet was gepost, voor de lol van al deze afleveringen. Het is goed om te zien dat u uw probleem zelf heeft opgelost. : D
@Firelord: Bedankt, maat. Tijdens het proces denk ik dat ik iets cools heb gedaan - ik heb mijn tablet opgestart zonder de binnenkant aan te raken ... het opstartimage komt van buitenaf (via `fastboot boot ...`) en de `/ system` partitie bevindt zich aan de SD-kaart, aanpasbaar aan wat ik maar wil. Zoiets als, een pc opstarten vanaf een USB-stick :-)
naki
2015-10-09 15:25:02 UTC
view on stackexchange narkive permalink

Het lijkt erop dat je al een oplossing voor je probleem hebt gevonden (er is veel tekst te lezen op deze pagina), maar het lijkt erop dat dit waarschijnlijk veel eenvoudiger had kunnen worden opgelost. 

  linuxbox # fastboot getvar all (bootloader) versie-bootloader: 3.03 (bootloader) versie-hardware: rev_c (bootloader) variant: LEOPARDCAT 16G (bootloader) versie-basisband: H00_0.16.F_0521 (bootloader) serienummer: 0a3dXXXX ... (bootloader) partitietype: systeem: ext4 (bootloader) partitiegrootte: systeem: 0x0000000080000000

Heeft uw tablet onder deze variabelen een max-download-size variabele? Als dat het geval is, kan dat een regelrechte waarschuwing hebben opgeleverd dat het knipperende proces problemen kan hebben met zo'n grote afbeelding. De huidige fastboot-code is gemaakt om te werken rond een max-download-size die te klein is, maar ik heb dezelfde fout ervaren, zelfs als de afbeelding kleiner is dan wat het apparaat zegt dat het aankan, dus eigenlijk is het punt een beetje omstreden, denk ik. 

  linux_box # fastboot flash system system.img fout: kan 'system.img'

niet laden Dus hoe dan ook, het lijkt hier dat je om welke reden dan ook niet kunt flitsen. Als jij en ik gelijk hebben, en het gaat om de grootte (je tablet heeft slechts 1 GB RAM, en proberen de meeste apparaten de hele afbeelding in RAM te lezen voordat ze knipperen), dan denk ik dat dit is waar de loutere aanpassing van het toevoegen van de -S -optie aan fastboot heeft misschien je flash hersteld zoals voor mij: 

  fastboot -S 512M flash system system.img

In plaats daarvan lijkt het erop dat u hebt geprobeerd uw afbeelding van 2 GB te forceren tot een grootte waarin (1) misschien niet kan worden gestopt en (2) niet de grootte is waarin uw de systeempartitie van het apparaat zou moeten zijn.

  • Met betrekking tot punt 1 zou ik in mijn ervaring niet rekenen op de broze Android-buildtools om te klagen als je ze zou vragen iets waar ze niet in zullen slagen, en het is mogelijk dat ze het hier hebben.

  • Wat betreft punt 2, ik geloof niet dat je dat niet zomaar kunt doen; aanvullende stappen zijn vereist om een ​​andere systeempartitiegrootte te gebruiken.

Ervan uitgaande dat uw tablet schaarse afbeeldingsbestanden verwacht, denk ik dat het commando dat u wilde proberen in plaats van make_ext4fs -l 1536M new_system. img / system was make_ext4fs -l 2048M -s new_system.img / system . De aangepaste opdracht maakt een afbeelding die wordt opgeblazen tot de juiste grootte, maar die tijdelijk wordt opgeslagen zonder overtollig vet, zoals grote zakken met lege gegevens: een ' dun afbeeldingsbestand' (zie de pagina waarnaar ik heb gelinkt eerder voor meer informatie over hen; ik heb niet genoeg reputatie op deze site om de link te herhalen).

Dit oude leesmij-bestand dat iemand schreef voor een verzameling tools zou moeten helpen begrijp hoe het proces verloopt.

Proost.

Bedankt voor het antwoorden. Wat betreft uw vragen, (1) nee, er was niets `max-download-` in de uitvoer van `getvar`. (2) Ik zal de optie `-S` in mijn toekomstige flashings in gedachten houden - zoals het is, zodra ik opstartte, werd ik root (door mijn kernel opnieuw te compileren) en` dd`-ed over de oude systeempartitie, dus of knipperen met -S zou werken zal moeten wachten op mijn volgende tests (3) Ik heb het geprobeerd met schaarse afbeeldingen, kreeg hetzelfde resultaat (dwz `fastboot` meldde dat knipperen OK was, maar de systeempartitie was in de war).
@ttsiodras Geen probleem. Ik heb tijdens het proces een aantal dingen geleerd. (1) Ah, oké. Ik betwijfelde of dit het geval was, zoals in ieder geval op mijn apparaat met behulp van de build van fastboot die ik heb geïnstalleerd, die variabele als eerste in de lijst wordt afgedrukt (bedankt, trouwens, voor het aantonen dat 'alles' kan worden doorgegeven aan getvar - dat is nuttig) . (2) Ohh, oké. Laat het ons weten als het werkt. (3) Oeps! Ik merkte dat niet. Het is veel tekst, sorry. Staat dat vermeld in uw berichten? (Was het zoals het commando make_ext4fs dat ik voorstelde, met `-s` en de volledige lengte van 2 GiB?) Misschien kan de tablet _niet_ omgaan met schaarse bestanden.
(3) ja, ik heb `-s` doorgegeven aan make_ext4fs - fastboot meldde 'OK' voor het branden, maar / systeem was in de war. Mijn theorie is dat, zoals je zei, alles wat groter is dan het geheugen van de tablet (1GB) niet zou werken, en de `-S` optie in fastboot nodig had om goed te werken (wat de half-verbroken toestand verklaart - de partitie was aangekoppeld omdat het eerste deel van de afbeelding in het geheugen paste en feitelijk werd gebrand, waardoor het kon worden gemount - maar de bestanden erin waren ... willekeurig beschadigd, afhankelijk van of hun sectoren werden gebrand of niet).
Metalx1000
2015-09-28 20:37:52 UTC
view on stackexchange narkive permalink

Met mijn Moto G heb ik een back-up gemaakt met dd zoals jij deed. Ik moest onlangs mijn systeempartitie herstellen, dus startte ik TWRP (ik heb het niet geflitst, ik heb gewoon de afbeelding naar RAM opgestart). Ik gebruikte toen adb om verbinding te maken terwijl TWRP actief was en ik pushte gewoon de img die ik met dd had gemaakt naar mijn SD-kaart en gebruikte vervolgens dd om de afbeelding naar de systeempartitie te schrijven.

Bekijk de video's die ik ' heb hierover hier gemaakt: https://youtu.be/BHCamV-sHx0?list=PLcUid3OP_4OVI1Rtuwxk1RjABh1PxXXQq

Helaas helpt dat me niet - ik kan het herstel van mijn tablet niet bereiken, ongeacht welke toetsencombinatie ik heb geprobeerd (ik heb het daarentegen meteen op mijn MotoG2 gekregen - dus het herstel van deze tablet wordt op de een of andere manier afgespeeld). Ik kan de herstelpartitie flashen (aangezien flashboot operationeel is) maar ik heb geen `recovery.img` van Asus, en er bestaat ook geen CWM of TWRP (voor een ME103K).


ⓘ
Deze Q&A is automatisch vertaald vanuit de Engelse taal.De originele inhoud is beschikbaar op stackexchange, waarvoor we bedanken voor de cc by-sa 3.0-licentie waaronder het wordt gedistribueerd.
Loading...