Install with ubports installer resulted in having a debug kernel

Keneda

@fubuntu
Well, surprisingly I would not trust Fairphone page, as they don't advertise brick risk for downgrading FP5 which is for sure rollback "protected".
Eos is much better trustable on this i guess.
If I were you I would really not attempt to downgrade FP4.

wynn1212

@fubuntu
To Clarify
FP4 comes with anti rollback protection and it will only trigger if your bootloader is LOCKED.
If your bootloader is UNLOCKED, then anti rollback protection is ignored

From what you read in the /e/OS installation instructions

Caution: The FP4 comes with an anti-rollback feature. (...) If you try installing a version of /e/OS based on a security patch that is older than the one on your device, you will brick your device.

That is true if you try to relock your bootloader, as in the detail of /e/OS installation instructions caution section

Rollback protection errors trigger if you install an update whose version number is LESS than the rollback index’s value stored on device.
(...)
Rollback protection errors are FATAL when the bootloader is LOCKED.
Rollback protection errors are IGNORED when the bootloader is UNLOCKED.

In short, if you unlock your bootloader and downgrad your FP4, you won’t trigger anti-rollback protection as long as you don’t relock the bootloader.

Also, you cannot relock your bootloader with Ubuntu Touch installed anyway.

@Keneda It's safe to downgrae FP4 to FPOS11 as long as you don't relock your bootloader. My FP4 came with FPOS13 from the factory, and I successfully downgraded to FPOS11 and install Ubuntu Touch in April 2024. Just DON'T relock your bootloader, as the FP4 will reset get_unlock_ability to 0 after the first FPOS11 boot. If you accidentally relock your bootloader with get_unlock_ability: 0, then there is no way to unlock your bootloader again.

If you want to retain get_unlock_ability: 1 after the downgrade, just don't boot FPOS afterwards. (Source: https://forum.fairphone.com/t/how-do-i-obtain-get-unlock-ability-set-to-1-on-an-unlocked-fairphone-4/105018/4)

Keneda

@wynn1212
Thanks for clarifying.
Is the same applies to FP5 ?

Mario.CH

Hi @wynn1212,

Wow ---- Wow => Thank you very much.

There are very few such fundamental and logical explanations here in the forum.

I simply had to rate you positively.

Thanks again.

Greetings Mario

wynn1212

@Keneda
It should be the same as described in the /e/OS installation instructions for Fairphone FP5 (Especially in the detail of caution section) and the Manage the Bootloader guide. However, I would suggest asking others who have successfully downgraded their FP5 or conducting further research first, as only the FP4 is available in my country (Sadly the sales representative in my country does not introduce FP5), and I cannot test with the FP5.

Regarding get_unlock_ability, I can’t confirm if the FP5 also has this issue where get_unlock_ability resets to 0. However, I would recommend checking this after the downgrade.

fubuntu

@wynn1212
Thanks! You might just have kept me from bricking my phone during the next installation attempt.

Mario.CH

Hi @fubuntu,

@fubuntu said in Install with ubports installer resulted in having a debug kernel:

But I also read the fairphone support page, and according to it, flashing with fastboot (downgrading included) should be no issue.

In my opinion, the “anti-rollback function” is an additional security feature to prevent customers from installing older Android versions on their device that are no longer supplied with further security updates.
This would give customers a false sense of security as they would consider their device safe with a locked bootloader.

For developers or customers who use their device as AOSP (Android Open Source Project), however, there is still the option of a rollback or installing a different operating system and using it with an open bootloader at their own risk.

See also source.android: lock and unlock the bootloader.

But I could also misunderstand, nobody is omniscient.

Greetings Mario

fubuntu

@TheVancedGamer
What does the maintainer think? Any idea how that debug kernel got installed?

TheVancedGamer

@fubuntu Some QCOM drivers seem to use trace_printk(), but honestly it's not something to bawl over, it's perfectly fine fwiw

Keneda

@TheVancedGamer

Some QCOM drivers seem to use trace_printk()

For clarifying, do you mean the android ROM came with this debug kernel because only on debug kernel this driver can use "trace_printk" ?

flohack

@Keneda Just a few 2 cents her:

Yes for porting we often set the Android build to build a so-called userdebug image. That ensures certain behaivour, but I am unsure if we really need that. So it could be that the FP4 kernel built during our porting build is set to debug since userdebug target is being used.

Someone could explore this by trying to build their own port with instructions from porting group and then see which flag is being used. It would be good to finally address this, since debug kernels are potentially slower than release.