Add Debian kernels to the CI

[lumag]

README.md by default advertises usage of Debian kernels, however this workflow is not tested and failed to build without #255 and #288 in place. PLease add a pipeline using Debian kernels to the CI, making sure that at least building of the image works with those kernels.

[lool]

The default kernel is a debian-style kernel derived from the debian one, I believe both changes were introduced in recent versions in -backports; thanks for the two PRs!

I want to switch to the latest backported kernel from Debian, we're just missing support for Agatti (at least RB1, UNO Q can come later), for which you've also helped revive the merge request in salsa (thanks!).

[lool]

Actually I'm not sure why it's broken for you, could you share how you triggered the error you were seeing?

@basak-qcom submitted a test PR using linux-image-arm64 yesterday:
#277

and it built and booted on RB3G2:
https://lava.infra.foundries.io/scheduler/job/151499#L2489

Linux debian 6.18.9+deb13-arm64 #1 SMP PREEMPT Debian 6.18.9-1~bpo13+1 (2026-02-13) aarch64 GNU/Linux

[lool]

Looks like this was introduced with 6.18.1-1~exp1, so not sure why it didn't affect the build above.

[lumag]

$ git log -1 --oneline
a19061085c73 (HEAD, origin/main, origin/HEAD) Merge pull request #286 from lool/bump-scratchsize
$ debos -m 4096MB debos-recipes/qualcomm-linux-debian-image.yaml
.....
(Reading database ... 41902 files and directories currently installed.)
2026/02/28 15:08:41 set -eux... | Preparing to unpack .../u-boot-efi-dtb_5~bpo13+1_all.deb ...
2026/02/28 15:08:41 set -eux... | Unpacking u-boot-efi-dtb (5~bpo13+1) ...
2026/02/28 15:08:41 set -eux... | Setting up u-boot-efi-dtb (5~bpo13+1) ...
2026/02/28 15:08:42 set -eux... |
2026/02/28 15:08:42 set -eux... | No services need to be restarted.
2026/02/28 15:08:42 set -eux... |
2026/02/28 15:08:42 set -eux... | No containers need to be restarted.
2026/02/28 15:08:42 set -eux... |
2026/02/28 15:08:42 set -eux... | No user sessions are running outdated binaries.
2026/02/28 15:08:42 set -eux... |
2026/02/28 15:08:42 set -eux... | No VM guests are running outdated hypervisor (qemu) binaries on this host.
2026/02/28 15:08:42 set -eux... | + rm /etc/kernel/postinst.d/u-boot-efi-dtb
2026/02/28 15:08:42 set -eux... | + dpkg-divert --rename --remove /etc/kernel/postinst.d/u-boot-efi-dtb
2026/02/28 15:08:42 set -eux... | Removing 'local diversion of /etc/kernel/postinst.d/u-boot-efi-dtb to /etc/kernel/postinst.d/u-boot-efi-dtb.distrib'
2026/02/28 15:08:42 set -eux... | + linux-version list
2026/02/28 15:08:42 set -eux... | + head -1
2026/02/28 15:08:42 set -eux... | + linux-version sort --reverse
2026/02/28 15:08:43 set -eux... | + latest_kernel=6.18.5+deb13-arm64
2026/02/28 15:08:43 set -eux... | + dtb_path=/usr/lib/linux-image-6.18.5+deb13-arm64
2026/02/28 15:08:43 set -eux... | + cp -RT /usr/lib/linux-image-6.18.5+deb13-arm64 /boot/efi/dtb
2026/02/28 15:08:43 set -eux... | cp: cannot create symbolic link '/boot/efi/dtb': Operation not permitted
2026/02/28 15:08:43 Action `Setup copying of DTBs to ESP partition` failed at stage Run, error: exit status 1

[lumag]

I see.. It didn't affect the build because @basak-qcom had cp -RT -> cp -RTL fix in his tree.

[lool]

Ah indeed; I guess you both tried this and fixed this at the same time

I checked, and the first backport with this change appeared about 3w ago:

[2026-02-06] [Accepted linux 6.18.5-1~bpo13+1 (source) into stable-backports ](https://tracker.debian.org/news/1713474/accepted-linux-6185-1bpo131-source-into-stable-backports/)(Debian FTP Masters) (signed by: Ben Hutchings)

It is indeed more than time to switch back to Debian kernels.

[lool]

I also want to note here: we need to move away from u-boot-efi-dtb and into normal edk2 boot. Using this is an extra boot architecture hack due to the specific situation on Agatti right now, but it adds yet another DT state to manage, and it's not versioned by kernel, creating subtle errors if someone tries to boot an older kernel (new dtb will still be installed by u-boot-efi-dtb and loaded by u-boot).

[lumag]

@lool then we need UKI, it seems to be the only sensible way to handle the DTB-with-older-kernels problem.

[lool]

@lool then we need UKI, it seems to be the only sensible way to handle the DTB-with-older-kernels problem.

Yeah, UKI is one way. I think the bootloader stub is another way (basically same selection of dtb based on hardware info as in UKIs with systemd-boot stub, but with a separate kernel and initramfs payload). We can explore UKIs on our side (coordination in #227), not sure if Debian can jump directly to UKIs or will want to keep the composable approach of discrete kernel + locally generated initramfs with signed modules.

[gagath]

This issue mentions both UKIs and using the upstream Debian kernels in the images. The first is already documented in #227 and discussion should happen there regarding u-boot-efi-dtb specifics if needed. For running the upstream Debian kernel, see #277 for implementation.