[4.14][10.0][TAMA][AKARI] Broken Treble

[Gouster4]

Platform:Tama Device:Akari Kernel version:4.14 Android version:10 Software binaries version:v3

Previously working on I was never able to boot any GSI on sodp base on Akari

Description After flashing any GSI (last time tryed Android 11 gsi) i ended up stuck at sony logo.

Symptoms Stuck at sony logo

How to reproduce download any gsi fastboot flash system gsi.img fastboot --disable-verity --disable-verification flash vbmeta vbmeta.img fastboot erase userdata

Additional context I tryed also without wiping userdata, without --disable-verity --disable-verification and also without flashing vbmeta. Always ended up stuck at sony logo

[MarijnS95]

I tried to reproduce your situation but the Android 11 GSI boots "fine" on Bahamut. There should not be anything specific preventing Tama/Akari from doing so either.

vbmeta appropriately covers only the system partition, and is fine to be left enabled. You should always wipe userdata.

As for Previously working on: Does a normal flashed SODP work correctly, before a GSI is flashed over it?

Please enable adb in the vendor build and see if a log can be obtained:

PRODUCT_PROPERTY_OVERRIDES += \
    ro.debuggable=1 \
    ro.adb.secure=0

[Gouster4]

I tried to reproduce your situation but the Android 11 GSI boots "fine" on Bahamut. There should not be anything specific preventing Tama/Akari from doing so either.

vbmeta appropriately covers only the system partition, and is fine to be left enabled. You should always wipe userdata.

As for Previously working on: Does a normal flashed SODP work correctly, before a GSI is flashed over it?

Please enable adb in the vendor build and see if a log can be obtained:

PRODUCT_PROPERTY_OVERRIDES += \
    ro.debuggable=1 \
    ro.adb.secure=0

yes, sodp rom booted fine. will try to catch logs

[Gouster4]

device isnt seen by adb. even after PROPERTY_OVVERIDES. Sodp rom shows: adb shell akari:/ # getprop ro.debuggable 1 akari:/ # getprop ro.adb.secure 0 akari:/ #

[MarijnS95]

~That comment clearly shows that you have access to adb?~

Nvm, I am confused with a different situation, where having access to adb shell without having access to adb logcat is called "I have no adb" :man_facepalming:.

[Gouster4]

where having access to adb shell without having access to adb logcat is called "I have no adb" 🤦‍♂.

used adb shell in sodp rom with that PROPERTY_OVVERIDES to check if it really changed props. Then after flashing GSI and erasing data, i have no adb access.

How else i can catch logs?

[Gouster4]

pstore

[Gouster4]

MartinX3 found from pstore it wants keymaster 4.0. Needs to be faked on keymaster 3.0 devices like Akari and older. Good Luck if u guys would do that.

[MartinX3]

I just say it doesn't work because of keymaster 3.0 (it is many times mentioned in the pstore everywhere) and that it works on devices with keymaster 4.0 like the XZ3 :D

[MartinX3]

Could be the same issue like https://github.com/sonyxperiadev/bug_tracker/issues/547 https://github.com/sonyxperiadev/bug_tracker/issues/527

[MarijnS95]

MartinX3 found from pstore it wants keymaster 4.0.

That is totally incorrect.

Martin reminded me again of the fact that it only seems to work on KM4 devices (Griffin and Bahamut from Kumano, and Akatsuki), which instantly lit a bulb :bulb: We had problems with versioning before in KM4, but as it turns out the KM3 implementation does something finicky too. It requires ro.build.version.release to be a version number (like Android 8.1) and doesn't allow it to be a letter like R on the Android 11 preview GSI. If this service refuses to start the phone will refuse to boot.

The easiest way is to trick it by overriding in the vendor image with:

PRODUCT_PROPERTY_OVERRIDES += \
  ro.build.version.release=11

[MarijnS95]

@MartinX3 Yoshino devices are a different game. ~All except Maple do~ Only maple does not have a vendor partition, just like Loire and Tone. All the necessary files reside on /system/vendor which does not persist a GSI flash.

@ix5 Has done work on that and afaik also distributes working builds on XDA. The last solution reuses the unused cache partition, or wraps vendor and odm in a single one, iirc.

[MartinX3]

@MartinX3 Yoshino devices are a different game. All except Maple do not have a vendor partition, just like Loire and Tone. All the necessary files reside on /system/vendor which does not persist a GSI flash.

Ups, I thought all yoshinos except maple having a vendor partition.

[MarijnS95]

@MartinX3 It is apparently the reverse of what I said: Maple is the "old" flagship without vendor partition, and Lilac/Poplar the newer but smaller brothers with vendor partition. In that case I don't exactly know what's wrong. Those issues seem different as there's (likely) no preview GSI involved with a letter in ro.build.version.release, but I can't say for sure as there's no information nor followup whatsoever.

[Gouster4]

still stuck at boot logo even with

PRODUCT_PROPERTY_OVERRIDES += \
  ro.build.version.release=11

new pstore (exactly same as before)

[MarijnS95]

If your example is anything to go by, you missed a backslash. It's easier and safer to copy-paste this than to type it over...

[Gouster4]

just not inserted into code. backslash is not shown.

[MarijnS95]

hmm, the usual key creation failure. Have you tried clearing userdata again? Otherwise try to set the version to 10 instead, it might be hardcoded to break on anything over that...

[Gouster4]

yes. cleared userdata when tryed. but maybe forgot when reflashed for cahtching pstore

[yuezhenglingluan]

@MartinX3 It is apparently the other way around, as Maple is the "old" flagship and Lilac/Poplar the newer but smaller brothers. In that case I don't exactly know what's wrong. Those issues seem different as there's (likely) no preview GSI involved with a letter in ro.build.version.release, but I can't say for sure as there's no information nor followup whatsoever.

isn't all device that is shipped with oreo are treble compatible, also on xda i see a tread that a user that make maple gsi-compatible by patching something int this thread: https://forum.xda-developers.com/xz-premium/development/pt-t3881123 also i can flash vendor image that i build for poplar with fastboot flash vendor vendor.img, if poplar use system/vendor i don't think i can do that.

[yuezhenglingluan]

@MartinX3 Yoshino devices are a different game. All except Maple do not have a vendor partition, just like Loire and Tone. All the necessary files reside on /system/vendor which does not persist a GSI flash.

@ix5 Has done work on that and afaik also distributes working builds on XDA. The last solution reuses the unused cache partition, or wraps vendor and odm in a single one, iirc.

also referring to this thread: https://forum.xda-developers.com/xperia-xz1/development/project-treble-pure-android-8-1-0-t3752281 that poplar was able to boot gsi on stock 8

[MarijnS95]

isn't all device that is shipped with oreo are treble compatible

Maple, the XZ Premium, was released with Android 7.1.

Poplar and Lilac, as stated in my correction, are released with 8.0 and do indeed have a separate vendor partition which makes it possible to support Treble out of the box.

also on xda i see a tread that a user that make maple gsi-compatible by patching something int this thread: https://forum.xda-developers.com/xz-premium/development/pt-t3881123

As far as I know @ix5 has assisted and/or provided the methods to make that possible.

also i can flash vendor image that i build for poplar with fastboot flash vendor vendor.img, if poplar use system/vendor i don't think i can do that.

Yes, I mentioned in my correction that it is the other way around. XZ1 (Compact) is newer and has this vendor partition.

also referring to this thread: https://forum.xda-developers.com/xperia-xz1/development/project-treble-pure-android-8-1-0-t3752281 that poplar was able to boot gsi on stock 8

Yes.

Edited the above messages to be more clear about this correction.

[Gouster4]

pstore with:

PRODUCT_PROPERTY_OVERRIDES += \
  ro.build.version.release=10

[MarijnS95]

@Gouster4 Can you set it back to 11, then check in AOSP what values you get for the following properties?

getprop ro.build.version.release
getprop ro.build.version.security_patch

Those are the only two props read by keymaster unless there's other external blobs involved, too.

I don't fully comprehend what's wrong. This could be something obvious and resolved before, but I might have to flash this GSI on a KM3 device and debug what exactly is going on.

EDIT: I just remembered that the TZapp behind keymaster likely looks at the SPL in the bootimage. Try to override both the android version and the date:

PRODUCT_PROPERTY_OVERRIDES += \
  ro.build.version.release=10 \
  ro.build.version.security_patch=2020-02-05

[Gouster4]

@Gouster4 Can you set it back to 11, then check in AOSP what values you get for the following properties?

getprop ro.build.version.release
getprop ro.build.version.security_patch

Those are the only two props read by keymaster unless there's other external blobs involved, too.

LineageOS build (not GSI) which i was using as treble base didnt booted with

PRODUCT_PROPERTY_OVERRIDES += \
  ro.build.version.release=11

log full of keymasters.

I don't fully comprehend what's wrong. This could be something obvious and resolved before, but I might have to flash this GSI on a KM3 device and debug what exactly is going on.

EDIT: I just remembered that the TZapp behind keymaster likely looks at the SPL in the bootimage. Try to override both the android version and the date:

PRODUCT_PROPERTY_OVERRIDES += \
  ro.build.version.release=10 \
  ro.build.version.security_patch=2020-02-05

I will try

[ix5]

Please close this issue. The keymaster binary is proprietary and there is little we can do to make it accept "wrong" non-release fingerprints, except maybe dirty workarounds.

One GSI is not like the other. There are differing things that need to be adjusted in the GSI itself as well, since even years after the introduction of Project Treble, the separation is still not 100% correct.

If you have a working solution to boot pre-release GSIs like Googles, please open a PR.

[Gouster4]

R beta gsi (official & erfan) booted on kagura even with keymaster v3... So it shouldnt be an issue... And it seems my kagura started working again, and i will have now more time to experiment with akari since i will daily use kagura.

Edit: (got some info, maybe helps) ᠌᠌gouster4: does R gsi depend on keymaster4? Because it seems to be an issue while booting on XZ2, but XZ has also keymastee v3 and there it boots just fine

Flame9914: It switches based on ur vendor preference .. but if vendor hal is different from aosp or calls an oem target apart from aosp..thn this can cause problem

[ix5]

The issue has been explained to you extensively.

Once again: The gist of the issue is that the tama km3 expects a numberic value for the release prop, whereas tone doesn't care. On R preview GSIs, the string is a letter. It's fairly easy to change the GSI build.prop.

You haven't made any steps to solve the issue yourself and ignored the solutions proposed to you so far.

Instead, you've talked about unrelated LineageOS builds and promised to "try" Marijn's solution, but nothing seems to have come of that.

@jerpelea please close this issue.

[Gouster4]

I did tryed Martin's solution... With same issues.

[MarijnS95]

I did tryed Martin's solution... With same issues.

Careful... Martin or Marijn? We are two different persons, both providing info on the topic.

Same question again; after applying the workaround including security_patch, send us the pstore so we can validate what is going on. Without logs we can't do anything for you.

numberic value

:joy:

[ix5]

numberic value

joy

Sh**... I swear that's a typo :joy: