Analyse des problèmes de démarrage d'un boot.img

Rédigé par NaïLyK Aucun commentaire
Classé dans : android, omnirom Mots clés : android, omnirom, pie, portage, shinano

L'une des choses à faire pour dépanner un probleme de boot lié au ramdisk, est d'essayer un ramdisk qui est connu pour fonctionner.

De l'article précedent, j'ai deux TWRP, un qui est fonctionnel, l'autre que j'essaye de dépanner.
Je vais donc faire des tests croisés, gràce à l'outil de osm0sis: https://shaarli.nailyk.fr/?laIuDw (lien vers le shaarli au cas où il disparaisse d'ici: https://github.com/osm0sis/mkbootimg )

 mkdir /tmp/mkbootimg
 cd $_
 wget "https://github.com/osm0sis/mkbootimg/archive/master.zip"
 unzip master.zip
 cd mkbootimg-master
 make -j 4


L'aide:

nailyk@nailyk :) % ./unpackbootimg                                                                                                                                                                                                              /tmp/mkbootimg/mkbootimg-master
usage: unpackbootimg
        -i|--input boot.img
        [ -o|--output output_directory]
        [ -p|--pagesize <size-in-hexadecimal> ]


Le TWRP en train d'être dépanné: recovery.img
Le connu pour fonctionner: twrp_z3_2018-11-03_unsecure.img

Extraction:

./unpackbootimg -i /tmp/recovery.img -o BAD/
./unpackbootimg -i /tmp/twrp_z3_2018-11-03_unsecure.img -o OK/
-rw-r--r-- 1 nailyk nailyk    9 nov.   3 17:05 recovery.img-base
-rw-r--r-- 1 nailyk nailyk    1 nov.   3 17:05 recovery.img-board
-rw-r--r-- 1 nailyk nailyk  194 nov.   3 17:05 recovery.img-cmdline
-rw-r--r-- 1 nailyk nailyk 274K nov.   3 17:05 recovery.img-dtb
-rw-r--r-- 1 nailyk nailyk    5 nov.   3 17:05 recovery.img-hash
-rw-r--r-- 1 nailyk nailyk    9 nov.   3 17:05 recovery.img-kerneloff
-rw-r--r-- 1 nailyk nailyk    8 nov.   3 17:05 recovery.img-oslevel
-rw-r--r-- 1 nailyk nailyk    6 nov.   3 17:05 recovery.img-osversion
-rw-r--r-- 1 nailyk nailyk    5 nov.   3 17:05 recovery.img-pagesize
-rw-r--r-- 1 nailyk nailyk 5,9M nov.   3 17:05 recovery.img-ramdisk.gz
-rw-r--r-- 1 nailyk nailyk    9 nov.   3 17:05 recovery.img-ramdiskoff
-rw-r--r-- 1 nailyk nailyk    9 nov.   3 17:05 recovery.img-secondoff
-rw-r--r-- 1 nailyk nailyk    9 nov.   3 17:05 recovery.img-tagsoff
-rw-r--r-- 1 nailyk nailyk 5,0M nov.   3 17:05 recovery.img-zImage

Les fichiers ont des noms comprehensible.
Etape suivante: vérifier que le ramdisk n'est pas corrompu:
(ici, le ramdisk est en lzma, pas en gz car il fallait une compression plus forte pour faire tenir le recovery.img dans la partion, et seul ces deux formats sont supportés par le bootloader)

<pre>
mkdir ramdisk
cd ramdisk
mv ../recovery.img-ramdisk.gz ../recovery.img-ramdisk.gz.lzma
lzma -d ../recovery.img-ramdisk.gz.lzma
cpio -i < ../recovery.img-ramdisk.gz
ls -1
    acct
    bin
    bugreports
    charger
    config
    d
    data
    default.prop
    dev
    etc
    file_contexts
    file_contexts.bin
    fstab.qcom
    init.rc
    init.recovery.hlthchrg.rc
    init.recovery.qcom.rc
    init.recovery.service.rc
    init.recovery.usb.rc
    license
    mnt
    odm
    oem
    plat_file_contexts
    plat_hwservice_contexts
    plat_property_contexts
    plat_seapp_contexts
    plat_service_contexts
    proc
    product
    prop.default
    res
    sbin
    sdcard
    sepolicy
    storage
    sys
    system
    tmp
    twres
    ueventd.qcom.rc
    ueventd.rc
    vendor_file_contexts
    vendor_hwservice_contexts
    vendor_property_contexts
    vendor_seapp_contexts
    vendor_service_contexts
    vndservice_contexts


Première chose qui saute aux yeux, il manque le binaire /init

Sony faisant les choses très bien, il faut un init particulier pour pouvoir booter l'ordiphone correctement, et, lors de l'article précédent, pour résoudre des problèmes de compilation, j'ai purement et simplement enlevé l'init car il ne voulait pas construire.
Ceci pourrait être une piste à suivre, mais le kernel s'est plaint de ne pas trouver le ramdisk, pas de ne pas avoir d'init.
Ceci devrait être facile à vérifier avec les tests croisés.


Construction d'une image de boot de test:


./mkbootimg
error: no output filename specified
usage: mkbootimg
       --kernel <filename>
       [ --ramdisk <filename> ]
       [ --second <2ndbootloader-filename> ]
       [ --recovery_dtbo <recoverydtbo-filename> ]
       [ --cmdline <kernel-commandline> ]
       [ --board <boardname> ]
       [ --base <address> ]
       [ --pagesize <pagesize> ]
       [ --dt <dtb-filename> ]
       [ --kernel_offset <base offset> ]
       [ --ramdisk_offset <base offset> ]
       [ --second_offset <base offset> ]
       [ --tags_offset <base offset> ]
       [ --os_version <A.B.C version> ]
       [ --os_patch_level <YYYY-MM-DD date> ]
       [ --header_version <version number> ]
       [ --hash <sha1(default)|sha256> ]
       [ --id ]
       -o|--output <filename>

 

Mis à part les secondary, il faut tout spécifier:


./mkbootimg --kernel BAD/recovery.img-zImage \
--ramdisk OK/twrp_z3_2018-11-03_unsecure.img-ramdisk.gz \
--cmdline "$(cat BAD/recovery.img-cmdline)" \
--base $(cat BAD/recovery.img-base ) \
--pagesize $(cat BAD/recovery.img-pagesize ) \
--dt BAD/recovery.img-dtb \
--kernel_offset $(cat BAD/recovery.img-kerneloff ) \
--ramdisk_offset $(cat BAD/recovery.img-ramdiskoff ) \
--output /tmp/test.img

file /tmp/test.img
/tmp/test.img: Android bootimg, kernel (0x8000), ramdisk (0x2000000), page size: 2048, cmdline (msm_rtb.filter=0x3F ehci-hcd.park=3 dwc3.maximum_speed=high dwc3_msm.prop_chg_detect=Y coherent)

Tout semble ok, plus qu'a tester ;)

fastboot boot /tmp/test.img
adb shell uname -a
Linux localhost 3.4.123-OmniROM-g4332f698b4d-dirty #2 SMP PREEMPT Sat Nov 3 16:02:59 CET 2018 armv7l

J'avais taggué le kernel que je build -123 pour pouvoir le repérer. Ici c'est bien lui qui démarre, donc il s'agit bien d'un problème ramdisk.
Plus qu'a savoir quelle étape du ramdisk se passe mal ;)

 

Etant donné qu'ici ma théorie est que les binaire d'init sont manquant, prenons ceux du bon ramdisk pour les mettre dans l'autre:

cp ../../OK/ramdisk/sbin/init_sony ./sbin
cp ../../OK/ramdisk/init ./init
find . -print |cpio -H newc -o |gzip -9 > ../ramdisk.cpio.gz

./mkbootimg --kernel BAD/recovery.img-zImage --ramdisk BAD/ramdisk.cpio.gz --cmdline "$(cat BAD/recovery.img-cmdline)" --base $(cat BAD/recovery.img-base ) \/mkbootimg-master
--pagesize $(cat BAD/recovery.img-pagesize ) \
--dt BAD/recovery.img-dtb \
--kernel_offset $(cat BAD/recovery.img-kerneloff ) \
--ramdisk_offset $(cat BAD/recovery.img-ramdiskoff ) \
--output /tmp/test.img

Aucune importance de faire du gzip ici car l'image est juste démarrée, sans être flashée, pas de problème de taille de partition.

Après le fastboot boot l'ordiphone redémarre en mode bootloader. C'est bon signe, car le comportement à changé.

Dans le last_kmsg:

 

selinux: SELinux: Loaded policy from /sepolicy
type=1404 audit(7898.910:3): enforcing=1 old_enforcing=0 auid=4294967295 ses=4294967295
selinux: selinux_android_file_context: Error getting file context handle (No such file or directory)
type=1400 audit(7898.913:4): avc:  denied  { dac_override } for  pid=1 comm="init" capability=1  scontext=u:r:kernel:s0 tcontext=u:r:kernel:s0 tclass=capability permissive=0
init: execv("/init") failed: Permission denied
init: Security failure...
init: panic: rebooting to bootloader

 

Le ramdisk démarre bien, mais selinux empeche l'init de démarrer. De plus on note que le contexte est 'enforcing' ce qui va poser des problèmes.
Il faut donc:

  • désactiver selinux pour l'instant,
  • réparer le build du /init & /sbin/init_sony pour avoir une image fonctionnelle!

Écrire un commentaire

Quelle est la deuxième lettre du mot ldawf ?

Fil RSS des commentaires de cet article