[Nokia 2.3] Stuck at Logo

[pcurz]

Current Behavior:

Device is frozen in bootlogo

To reproduce

1. fastboot flash system-td-arm32_binder64-ab-vanilla.img
2. fastboot format:f2fs userdata (since with ext4 crashes and goes into recovery with data corrupt error)
3. fastboot reboot
4. won't pass bootlogo

   Describe the bug

   I think it has something to do with broken forceencrypt (see logs) however, there's no twrp to modify vendor (i even tried unpackaging vendor.img the hard way with no success)

Expected behavior

Actually boot the GSI

Smartphone (please complete the following information):

• Device: Nokia 2.3 (TA-1214)
• Build Flavor: system-td-arm32_binder64-ab-vanilla.img.xz
• Version: android_13.0.0_r41 ci-20230417

Additional context

In phh's version, crash section is the same, but happens after bootlogo, in bootanimation thus bootlooping

td_log170423.txt

[phhusson]

Try doing factory reset from recovery rather than fastboot

On April 17, 2023 6:51:02 PM GMT+02:00, pcurz @.***> wrote:

Current Behavior:

Device is frozen in bootlogo

To reproduce

1. fastboot flash system-td-arm32_binder64-ab-vanilla.img
2. fastboot format:f2fs userdata (since with ext4 crashes and goes into recovery with data corrupt error)
3. fastboot reboot
4. won't pass bootlogo

   Describe the bug

   I think it has something to do with broken forceencrypt (see logs) however, there's no twrp to modify vendor (i even tried unpackaging vendor.img the hard way with no success)

Expected behavior

Actually boot the GSI

Smartphone (please complete the following information):

• Device: Nokia 2.3 (TA-1214)
• Build Flavor: system-td-arm32_binder64-ab-vanilla.img.xz
• Version: android_13.0.0_r41 ci-20230417 Latest

Additional context

In phh's version, crash section is the same, but happens after bootlogo, in bootanimation thus bootlooping

td170423.txt

-- Reply to this email directly or view it on GitHub: https://github.com/TrebleDroid/treble_experimentations/issues/23 You are receiving this because you are subscribed to this thread.

Message ID: @.***>

[pcurz]

Can't get into recovery, is stuck in "No Command" I tried with some combination to keys for trigger but nothing

If i wipe userdata as ext4, device restarts and i think it goes into recovery with message "can't load android system. your data may be corrupt" with two options

• try again
• factory data reset

here i wiped data and same result, your data may be corrupt, in this state it doesn't even try to boot

[pcurz]

I find odd those "set property" errors at the beginning with error code 0x18, probably some missing permissions?

[pcurz]

EDIT: i can access recovery now, wiped /data f2fs Update: deleting /vendor/lib/keystore* (there's no lib64) is still the same Update 2: deleting files never happened (because the files came back) Update 3: now i really deleted the files, still bootloop and logs are the same log (2).txt

[pcurz]

uh it seems that i was trying nonsense things, this seems to be sepolicy related? because of

libc    : Unable to set property "ro.product.nickname" to "Ironman_00WW": error code: 0x18
avc: denied { set } for property=
ro.product.nickname pid=272 uid=0 gid=0 scontext=u:r:vendor_init:s0 tcontext=u:object_r:default_prop:s0 tclass=property_service permissive=0

There is selinux folder from /vendor/etc, any hints? selinux.zip

[phhusson]

Why do you think not being able to set nickname would prevent booting? Check your vendor fstab (/vendor/etc/fstab.xxxx) to confirm whether your device is supposed to use f2fs or ext4

When taking logs, use adb logcat -b all your logs seem to be missing that -b all that can contain useful information

[pcurz]

Why do you think not being able to set nickname would prevent booting? I mean, there is even avc: denied { ioctl } for path="/dev/tmp-phh" dev="tmpfs" ino=9982 ioctlcmd=0x125d scontext=u:r:phhsu_daemon:s0 tcontext=u:object_r:device:s0 tclass=blk_file permissive=1 Unless that's expected behavior

Check your vendor fstab (/vendor/etc/fstab.xxxx) to confirm whether your device is supposed to use f2fs or ext4 Here is fstab.mt6761, seems to use ext4 in userdata, but ext4 doesn't get past the logo, it reboots into recovery with "can't load android system. your data may be corrupt", wiping on the same recovery results in the same thing fstab.zip

When taking logs, use adb logcat -b all your logs seem to be missing that -b all that can contain useful information Thanks i will, but my path seems to be through ext4 which is what the vendor asks for, however it won't go beyond bootanimation, how do i get logs in this state? EDIT: I need TWRP for this, i will get a barebones one running

[phhusson]

Thanks i will, but my path seems to be through ext4 which is what the vendor asks for, however it won't go beyond bootanimation, how do i get logs in this state?

Have you tried running adb logcat?

[pcurz]

Thanks i will, but my path seems to be through ext4 which is what the vendor asks for, however it won't go beyond bootanimation, how do i get logs in this state?

Have you tried running adb logcat?

Well, adb doesn't detect devices at this stage, it stays waiting for the device, or will it be simpler to modify the boot.img to deactivate the authorization (recovery is here, not apart)? in my case adb is always activated in recovery, but it is with the authorization but without being able to accept it obviously

[pcurz]

nvm i got twrp working with adb, i will take logs this weekend, the "modify boot.img" idea is simple and difficult at the same time because of SELinux screaming at me lol

[pcurz]

Ok so i did the following reboot into bootloader fastboot flash system system.img (ci-20230706) fastboot reboot recovery (remember when i said that in stock recovery i was stuck in no command, i've just repacked it with ro.debuggable=1 so it goes automatically in the menu, nokia disabled button combinations when this device got android 11, in android 9 i could maintaining power and vol +, anyways) wipe /data reboot into bootloader again fastboot flash boot twrp.img (before was stock recovery) fastboot reboot wait for boot... hangs on bootlogo and reboots in recovery pull logs

oh, and i added printk.devkmsg=on to boot.img cmdline because there's no last_kmsg If I got the logs wrong, please let me know, thanks!

kmsg.txt console-ramoops-0.txt

[pcurz]

Ok this is embarassing, i mounted my stock oem vendor image in ubuntu as rw, and deleted /vendor/lib/hw/keystore.T99621AA3.so /vendor/lib/hw/keystore.mt6761.so

flashed it back Now it boots ci-20230706 (system-td-arm32_binder64-ab-vanilla.img.xz)!! I don't know where to apply this in runtime to not need the modification of the vendor in future updates

[pcurz]

Device securize automatically, also even after restoring vendor without those changes, and wiping data, the issue doesn't happen magically, i can live with that since i can finally run gsi, but still this is weird (what a weird phone i have) lll.txt

well it "does" work when restoring stock vendor, but it's just a time bomb because in some reboots it will fail to boot with again /data corrupt, so yeah, i will make a PR with the workaround

[phhusson]

Sorry, I'm trying to read back everything you said and I'm completely confused.

You mention "device securize automatically" does that mean that on first boot of GSI you have working su and then after a reboot you no longer do?

The console-ramoops-0 log you sent is non-sense. It looks like you tried to boot an arm64 image on an arm32_binder64 device?

When hitting the actual keymaster issue you mention you should get a pmsg-ramoops-0 in twrp's /sys/fs/pstore, can you grab that?

[pcurz]

About "device securize automatically" yes i had ADB without confirmation plus su, but then su disappeared and adb asked for confirmation, also the name of the device changed to Nokia 2.3. But this happens when i undid the workaround and wiped /data again from stock recovery to see if the issue came back, but I think that the fact that GSI kept booting after undoing the keymaster workaround was because /data was not being wiped correctly, i mean, it was never wiped but it made believe that it was. I'm sorry, i hope this mess is understood, but when i realized what was happening i began to question my reality because of the securize thing and the device booting fine without the workaround.

I think that for this i'll have to test copying some file or installing an app, try to format /data from and see if the data persists

The way i was able to undo this mess was to flash these stock files from mtkclient So going back to the beginning, try to boot GSI, reboot to recovery and ask for wipe /data, initial issue persists and so on.

About /sys/fs/pstore, there is only console-ramoops-0, and always the exact same log, no matter how i try to boot without any modification, and with modifications i mean only the the keymaster one, also gsi is a64, i verified it.

When I can, I'll consider wiping with twrp, it's more verbose, I remember that when I captured the logs it said rescue party trigger with reason cryptofail something, which honestly gave me a better clue than console-ramoops-0 itself and that's where that workaround came from, but I insist i will clarify this information as soon as possible.