Próbowałem sflashować system.img Wziąłem z dd - błąd

Wieloletni facet z UNIX, ale stosunkowo nowy w świecie Androida. Czytaj.

EPISODE 1: A New Backup (miałem nadzieję)

Niedawno kupiłem Asus MemoPAD (ME103K); Następnie zostałem rootem i zapisałem ddobraz systempartycji tylko do odczytu na zewnętrznej karcie SD:

$ 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

Rozmiar (dokładnie 2GiB) był nieco podejrzany - czy mogło tak być z powodu partycji FAT32 na karcie SD?

Nie, nie zostało - tune2fs -lujawniono, że to rzeczywiście był prawidłowy obraz EXT4, dokładnie wielkości 2GiB, który przeszedł fsck -fbez żadnych błędów. I fastboot(z maszyny linux podłączonej do tabletu) zgodził się, po 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

Ten rozmiar to rzeczywiście 2 GB:

linuxbox# python2 -c 'print 0x0000000080000000'
2147483648

Tak więc wszystko jest dobrze - mam kopię zapasową obrazu. Teraz przetestuj przywracanie.

Próbuję sflashować system.img z powrotem na tablet - aby upewnić się, że mogę odzyskać wszystko, rodzaj kuloodpornej kopii zapasowej, którą wykonujemy w świecie Unixa ( np. Przywracanie zawartości dysku za pośrednictwemdd if=backup.image of=/dev/sdXXX ).

Wszystko związane z adbi fastbootdziała bezbłędnie - więc próbuję ...

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 Pobieram i buduję android-tools-5.1.1swoją dystrybucję ze źródeł, dodając informacje o debugowaniu - i wchodzę do debuggera, aby zobaczyć ten błąd:

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

Ciekawe - choć jestem w komputerze 64-bitowym, najwyraźniej istnieją problemy, które z kolei rozmiar pliku „negatywny” (w świecie 32bit, rozmiar pliku mojego obrazu, 2 ^ 31, jest rzeczywiście uznać negatywne - a dokładnie, -2147483648.

OK, w porządku - jak flashują duże pliki obrazów w Androidzie?

Googlowanie, wyszukiwanie - okazuje się, że korzystają z tego make_ext4fsnarzędzia, które tworzy flashowalne obrazy. W rzeczywistości jest to część tego, co właśnie skompilowałem, więc równie dobrze mogę go użyć:

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

Fajnie - więc najwyraźniej mogę budować obrazy systemowe ze zwykłych starych folderów. Niebo będzie moim ograniczeniem - będę mógł dodać do tego obrazu wszystko, co chcę.

Spalmy to ...

linuxbox# fastboot flash system new_system.img
erasing 'system'...
OKAY [  0.064s]
sending 'system' (2088960 KB)...
^C

Czekałem 1 godzinę, zanim uderzyłem w Ctrl-C. I musiałem ponownie włączyć tablet, który uruchomił się ponownie w trybie fastboot.

To nie wygląda dobrze.

Co jeśli zbuduję mniejszy obraz? Być może 2 GB stanowią problem, a ta partycja nie jest w pełni wykorzystana - ma wolne miejsce:

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, wygląda to bardzo obiecująco (zajęło to tylko 5 minut). Chyba mogę teraz zrestartować komputer i wszystko powinno być normalne, tak?

Nie :-)

I nie przeszkadza tymczasowo zamurowane urządzenia, tak długo, jak nie dostać się do kontrolowania go w końcu (maszyny, że nie jestem mistrzem, to maszyny nie dbają działać ;-)

Wszelkie pomysły na to, co zrobiłem źle i co mogę zrobić, aby to naprawić?

Z góry dziękuję.

PS Sprawdziłem stronę pomocy Asusa dla mojego tabletu - zawierają one tylko źródła jądra oraz plik .zip Over-the-air. To z kolei zawiera kopię zapasową na poziomie systemu plików z katalogu głównego - tzn. systemFolder istnieje tam tylko jako folder, a nie obraz, a nie to system.img, co mogę sflashować - więc to mi naprawdę nie pomaga.

EPISODE 2: Atak niestandardowych butów

Wobec braku jakiegokolwiek rodzaju recovery.imgod Asusa (dlaczego producent miałby zawracać sobie głowę publikowaniem szybkiego flashowania recovery.img? Dlaczego rzeczywiście ...) i podobnej nieobecności na obrazach odzyskiwania z witryn CWM i TWRP ... Zostaję walczyć ze wszystkimi sam.

Na szczęście plik aktualizacji Over-the-air od Asusa zawiera w nim ...

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

... obraz rozruchowy mojego tabletu. Teraz może - tylko może - mogę coś z tym zrobić.

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

Rozszerzanie ramdysku ...

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

Skonfigurowałem default.proprootowanie, gdy jądro uruchamia się:

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

Skopiowałem też /system/bin/sh( z bezprzewodowego pliku .zip Asus ) do /sbin/sh. To samo zrobiłem z busybox - całkiem przydatnym narzędziem.

I przepakowałem 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

abootimgtak naprawdę nie powiodło się po pierwszym uruchomieniu, ponieważ bootimg.cfgmusiałem zostać zaktualizowany - bootsizeparametr musiał zostać zmieniony, ponieważ pakiet jest teraz większy. abootimgzgłasza, czego potrzebuje, więc to dość proste.

A teraz uruchamiam mój niestandardowy obraz ...

linuxbox# fastboot boot new_boot_busybox.img

... i obserwuj następujące ...

linuxbox# adb logcat
- exec '/system/bin/sh' failed: Permission denied (13) -

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

Hmm ... Może adbd nie jest uruchamiany jako root?

linuxbox# adb root
restarting adbd as root

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

Dobra ... I hexedit adbd i patch / system / bin / sh to / sbin / sh (skopiowałem / system / bin / sh z obrazu OTA do rootfs initrd): Reboot, fastboot ...

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

Cerować. Czy to coś może zrobić?

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

To jest ... zobaczmy:

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, więc / system jest zamontowany. Czy mogę zobaczyć, co jest w środku?

linuxbox# adb pull /system
remote object '/system' does not exist

Co do ... Może mogę sprawdzić, co zawiera / proc / kmsg (co wyświetliby „dmesg”)

linuxbox# adb pull /proc/kmsg
failed to copy '/proc/kmsg' to './kmsg': Operation not permitted

Nie, muszę być rootem, żeby to zrobić.

linuxbox# adb push /sbin/sh /system/bin/sh
failed to copy '/sbin/sh' to '/system/bin/sh': Permission denied

I to też.

To okazuje się niezłą łamigłówką ...

Odcinek 3: Return of the Shell.

Jeśli kiedykolwiek miałem szansę rozwiązać ten problem, najpierw musiałem dowiedzieć się, dlaczego skorupa nie działa. adbdsam odpowiadał, więc został uruchomiony po stronie tabletu - ale nie mógł wykonać powłoki, nawet gdy załatałem ją, by wywołać plik ( /sbin/sh), który sam umieściłem na obrazie rozruchowym - mając 100% pewności, że miał odpowiednie uprawnienia i był dostępny z shellkonta (id = 2000), które adbdużywa.

Co pozostawiło tylko jedno wyjaśnienie - „klatki” SELinuksa.

Sprawdziłem więc, jak adbdpowstały moje obrazy rozruchowe 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

... i próbowałem oczywistej zmiany:

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

Zapakowałem ponownie i ku memu wielkiemu zadowoleniu zobaczyłem ...

linuxbox# adb shell
$ 

W końcu uzyskałem dostęp do tabletu - z „wnętrza”.

Sprawdzając zamontowany / system, stało się jasne, że proces flashowania - nawet jeśli fastboot flash system ...zgłosił, że wszystko jest w porządku - zakończył się spektakularnie . Cudem było, że partycja została zamontowana w pierwszej kolejności.

To wyjaśniło, dlaczego tablet się nie uruchamia, i dało mi ostateczny pomysł, który rozwiązał problem.

Musiałem uruchomić tablet, aby używał mojej nieskazitelnej kopii partycji / system, ale w tym momencie, mimo że miałem dostęp do powłoki, nie byłem rootem - ( zmiany, które wprowadziłem, default.propnajwyraźniej są ignorowane przez jądro Asusa - Niedługo będę musiał go ponownie skompilować ... ), aby nie móc zamontować zewnętrznej karty SD ddna dobrej kopii.

Ale miałem własny obraz rozruchowy - co oznaczało, że mogłem edytować jego /fstab.qcomwnętrze i zrobić to:

Oryginalna linia informująca tablet o sposobie montażu / systemu

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

Moja zmiana

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

... i z powrotem w moim pudełku z linuksem, ddpodłączyłem nieskazitelną kopię zapasową partycji systemowej tabletu do drugiej partycji mojej zewnętrznej karty SD - którą utworzyłem, gpartedaby mieć dokładnie 2 GB.

Tak się stało - tablet uruchomił się z mojej zewnętrznej karty SD.

EDYCJA : Podróż trwała - w końcu załatałem i skompilowałem własne jądro i zrootowałem .

Wygląda na to, że już znalazłeś jakieś rozwiązanie swojego problemu (na tej stronie jest dużo tekstu do przeczytania), ale wygląda na to, że prawdopodobnie można go rozwiązać znacznie prościej.

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

Czy wśród tych zmiennych Twój tablet zwrócił max-download-sizezmienną? Jeśli tak, może to być ostrzeżenie, że proces flashowania może mieć problemy z tak dużym obrazem. Obecny kod Fastboot został opracowany tak, aby obejść max-download-sizezbyt mały, ale wystąpił ten sam błąd, nawet jeśli obraz jest mniejszy niż to, co urządzenie mówi, że może sobie poradzić, więc w rzeczywistości chodzi o coś w rodzaju dyskusji.

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

W każdym razie wydaje się, że z jakiegokolwiek powodu nie możesz flashować. Jeśli ty i ja mamy rację, a chodzi o rozmiar (twój tablet ma tylko 1 GB pamięci RAM i podobno większość urządzeń próbuje odczytać cały obraz do pamięci RAM przed flashowaniem ), myślę, że w tym miejscu wystarczy sama modyfikacja dodania -Sopcji fastboot mógł naprawić flash tak jak dla mnie:

fastboot -S 512M flash system system.img  

Zamiast tego wydaje się, że próbowałeś zmusić obraz o wielkości 2 GB do rozmiaru, który (1) może nie być możliwy do wypchnięcia, a (2) nie jest wielkością, jaką powinna mieć partycja systemowa urządzenia.

• Jeśli chodzi o punkt 1, z doświadczenia wiem, że nie będę liczyć na kruche narzędzia do budowania Androida, na które można narzekać, jeśli poprosisz ich o zrobienie czegoś, na czym im się nie uda, i możliwe, że mogą tu mieć.

• Jeśli chodzi o punkt 2, nie wierzę, że nie możesz tego po prostu zrobić; wymagane byłyby dodatkowe kroki, aby użyć innego rozmiaru partycji systemowej.

Zakładając, że tablet oczekuje rzadkich plików graficznych, wydaje mi się, że polecenie, które chcesz wypróbować, to make_ext4fs -l 1536M new_system.img /systembyło make_ext4fs -l 2048M -s new_system.img /system. Skorygowane polecenie utworzy obraz, który zostanie napompowany do właściwego rozmiaru, ale zostanie tymczasowo pozbawiony nadmiaru tłuszczu, jak duże kieszenie pustych danych: „ rzadki plik obrazu” (więcej informacji na ten temat można znaleźć na stronie, do której podłączyłem wcześniej; Nie mam wystarczającej reputacji na tej stronie, aby powtórzyć link).

Ten stary plik readme, który ktoś napisał dla zbioru narzędzi, powinien pomóc zrozumieć, jak przebiega ten proces.

Twoje zdrowie.

Z moim Moto GI utworzyłem kopię zapasową używając dd, tak jak ty. Kiedyś musiałem przywrócić partycję systemową, więc uruchomiłem TWRP (nie flashowałem go, po prostu uruchomiłem obraz do pamięci RAM). Następnie użyłem adb do połączenia podczas działania TWRP i po prostu wcisnąłem obraz wykonany przez dd na moją kartę SD, a następnie użyłem dd do zapisania obrazu na partycji systemowej.

Sprawdź filmy, które zrobiłem na ten temat tutaj: https://youtu.be/BHCamV-sHx0?list=PLcUid3OP_4OVI1Rtuwxk1RjABh1PxXXQq