Install with ubports installer resulted in having a debug kernel

fubuntu

Two weeks ago I installed Ubuntu Touch on FP4 using the ubports installer for MacOS. It didn't go smoothly, because after the first step the installer lost contact to the phone (no device visible in fastboot mode anymore) and only after exchanging the Apple usb cable for one sold by Google it worked again. Later in the process the installer printed an error message saying a logical volume could not be deleted, but ignoring this seemed to go fine. I also tried to relock the bootloader, but it resulted in a bootloop, so I unlocked it again.

Then I had a look around, enjoying the smooth look and feel of Lomiri, but when I used the terminal to look at the dmesg output, I saw this:

NOTICE
trace_printk() being used. Allocating extra memory. This means that this is a DEBUG kernel and it is unsafe for production use. If you see this message and you are not debugging the kernel, report this immediately to your vendor!

Does Ubuntu Touch regularly use a debug kernel? If not, has anyone an idea what happened?

Keneda

@fubuntu
Kernel comes from the android version installed before installing Ubuntu Touch, not from Ubuntu Touch.
Did you use the android version said to be installed by UBports installer before installing UT ?

arubislander

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

Kernel comes from the android version installed before installing Ubuntu Touch, not from Ubuntu Touch.

This is not entirely correct. Yes, the kernel version is the same. But the kernel can be, and often is, recompiled. That is why a requirement to be able to port a device, is that the kernel source is available.

So what possibly happened here, is that the kernel was compiled with debug flags set.

OP's best bet is to het in touch with the porter of the FP4.

*Enrico13011978*

This is an interesting option with the kernel. If you install Ubuntu Touch although this is not quite compliant with the rules, you can install Twrp later at short notice. Quick question as I have already tried this myself and it worked. With this kernel on my hardware in the dev channel.kinesis-.-r2.1-4.14.343+openela-miatoll-05052024.zip. Ubuntu Touch has definitely started through you can try a lot.

fubuntu

@Keneda Actually, no... While my FP4 came with Android 12, during installation I noticed that on the device page Android 11 was required; but I thought it might work as well with a later version of Android. (And I wouldn't have known how to downgrade to Android 11.)

How can the version of the former OS, which is erased anyway, affect the installation of Ubuntu Touch? I only know of an Android rollback prevention concerning the security level of Android.

fubuntu

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

So what possibly happened here, is that the kernel was compiled with debug flags set.

OP's best bet is to het in touch with the porter of the FP4.

Ok... How do I find out who this is and how to reach him/her?

Thanks for your replies, all of you!

Keneda

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

which is erased anyway

Not all of android components are erased.
I invite you tu take a look at halium project.
https://halium.org/

Making it simple, because I don't understand all the process anyway, a device needs some closed source drivers to work properly, those drivers need the particular kernel they were shipped with to work properly, then an ubuntu touch port is done with this kernel and those drivers.

Using a different version of android to install Ubuntu Touch on top of it may work, or not, depending on the kernel and drivers used in this android version.

You could end in a perfectly working Ubuntu Touch device, or a device with phoning problems, or GPS problems, or battery problems... This because the porter optimised, tweaked, adapted his UT port to this kernel with those drivers.

Are you sure FP4 comes with anti rollback protection ?
I though it is only from FP5 that it infected FP phones ?

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

Ok... How do I find out who this is and how to reach him/her?

All the main porters are in FP4 device page : https://devices.ubuntu-touch.io/device/fp4/
Best would be to ping @TheVancedGamer or @flohack on the forum (which I just did) as they are the most active here from those.
Or to try on telegram : https://t.me/ut_troubleshooting

fubuntu

@Keneda
Thanks a lot for your explanations. So probably I caused any occurring problem myself. However, I'm still curious how that debug kernel came into play.

Are you sure FP4 comes with anti rollback protection ?

From what I read in the /e/OS installation instructions, yes:

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.

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

(Maybe the /e/OS installation script doesn't use fastboot flashing, but OTA Sideload?)

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. :clapping_hands_light_skin_tone: :thumbs_up_light_skin_tone:

I simply had to rate you positively. :face_blowing_a_kiss:

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. :grinning_face:

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.