debos: Switch to Debian's kernel from Experimental

[diederikdehaas]

Now that a kernel with the needed code and commits has landed in Debian Experimental, switch to that (from a self-built kernel).

Draft as that still hasn't actually happened, but it is ready for review.

Do NOT merge it at this time! (which Draft hopefully automatically prevents)

[diederikdehaas]

It's (probably) better to use a custom kernel as it's completely uncertain if any changes which are not part of 6.1 will be added to Debian's Bookworm kernel. So I'm closing this PR and the commits which enabled Sid/Experimental should probably be reverted.

[CounterPillow]

As long as the kernel config options are in there for the Quartz64, it's fine. Devicetrees can be packaged externally, unless you mean to say that the kernel config options also didn't make it in?

[diederikdehaas]

The ones from https://salsa.debian.org/kernel-team/linux/-/merge_requests/551 are there and that is sufficient ... for now.
But if there are Kconfig options or code fixes which are not in 6.1, then you won't get them (unless they get backported upstream to 6.1).

I hoped that as long as the upstream maintainer had accepted the patches, then it would be eligible to be added to the Debian kernel before they were in Linus' or GKH's Stable kernel tree. But what I suspected but didn't know until yesterday, is that the rules are stricter for the kernel version which is to be Bookworm's, which is 6.1.
If GKH won't accept it in the 6.1 Stable tree, then Debian would have to carry the patch(es) throughout Bookworm's existence and that is considered too great a risk.

[CounterPillow]

This seems good enough for me, we can provide device trees ourselves and all the important kernel stuff is in already. gregkh usually picks up everything with a Fixes: tag so I'm not too worried about out-of-tree patches being necessary for fixes.

If something shiny new and cool drops we can always provide our own kernel package again as an option, e.g. if someone writes a CSI driver or an NPU driver or rkvdec2.

[CounterPillow]

As an addendum, what speaks for using a Debian provided kernel for me, in order of importance:

• don't have to keep up with kernel updates myself (huge, as I don't want people to be without kernel security updates if I ever get hit by a car)
• don't have to awkwardly transition users away from my kernel a few years down the line
• provide as vanilla of a Debian kernel experience as possible

So really all that stands in the way of me merging this is that I still need to finish my device tree package, which involves filing a bug against u-boot-menu to tell them I want unversioned paths even if a versioned path with the device tree of the same name exists, and setting up aptly with a PGP key and all that jazz, and then adding that repository and package to the image generation.

[diederikdehaas]

So really all that stands in the way of me merging this is that I still need to finish my device tree package

Due to a Debian bug* the current (signed) version (6.1-rc3) in experimental does not have ANY dtb's, so that is critical ;-)

) It is fixed in Debian's 6.1-rc5 version, but that brought an upstream bug to light, which causes build failure on armhf and so the signed* package(s) have not been processed as of now.

[diederikdehaas]

don't have to awkwardly transition users away from my kernel a few years down the line

FYI: you could do that by turning your kernel package into an 'empty' transitional package which (version) Depends on the appropriate Debian kernel.

[adminy]

Is the kernel not modular enough or do we depend on an "edge" kernel feature for things to work? Or is there an actual kernel bug that only got fixed now?

[diederikdehaas]

People usually complain that Debian's kernel is too modular (=m by default) ;-P
First there was a bug where the dtb's weren't build, then there was a bug which prevented building on armhf.

Both have now been fixed with 6.1-rc6 upload. And I just saw that the signed version (for arm64) got build. Those should now be distributed across the archive mirrors, so I guess the switch could take place now.

[CounterPillow]

For the sake of explaining why this hasn't been merged yet: I first want to report a bug to u-boot-menu regarding unversioned device trees, so that our device tree package can be used, so that we can then switch to Debian's kernel without losing SOQuartz things.

[adminy]

Is this because dpkg -i /root/*.deb installs more than just the kernel yes? Or how is the u-boot-menu related to the kernel otherwise?

[CounterPillow]

It's related to picking which dtb is chosen in extlinux.conf.

What we'd like to be able to do is overwrite this with our own unversioned path, but it doesn't let us if a versioned default path exists, due to how they ordered their if conditions in the shell script they use. The effect is that our device tree package can't actually tell u-boot-menu to use its device trees.

[adminy]

and that's baked in the kernel package?

[CounterPillow]

no, in the u-boot-menu package, which is why I'm currently busy filing a bug report against it

[adminy]

I'm guessing the u-boot is packaged inside linux-image then.

[CounterPillow]

... no, why would you think that

there is no packaged u-boot

there's an u-boot-menu package, which provides a script to generate extlinux.conf. That is where the problem lies.

[adminy]

Sorry yes, that's what I meant to say, that linux-image must be containing this u-boot-menu package. So this script cannot be overwritten with debos then? After the apt action?

And I might be getting it wrong still, you mean that u-boot-menu is separate from linux-image yes?

[diederikdehaas]

No, that's (still) not correct.

Debian has a linux-image-arm64 (meta) package which depends on the latest current real kernel package and that is currently linux-image-6.1.0-0-arm64. That package contains the kernel and all the DTB's.

Debian also has various u-boot packages and for rockchip devices, you'd normally use the u-boot-rockchip package.

The u-boot-menu package is yet another separate package.

But there are several issues with the packages provided by Debian.

• The linux-image-* package contains the DTB's as provided by the upstream 6.1-* release and therefor misses several things that we want/need
• The u-boot-rockchip package does not contain anything wrt Quartz64 devices, so is of no use (at all)
• The u-boot-menu package does not (yet?) contain the logic we need to boot the Debian kernel, but use the DTB's provided by this project

HTH

[diederikdehaas]

The linux-image- package contains the DTB's as provided by the upstream 6.1- release and therefor misses several things that we want/need

FTR: The Debian kernel now does have the needed DTB's :-) See https://salsa.debian.org/kernel-team/linux/-/merge_requests/589