CI: mkosi-mainline using outdated "daily" kernel

[solardiz]

I just found out that our latest mkosi-mainline test, which ran yesterday, somehow used this kernel:

Linux version 6.11.0-061100daily20240916-generic (kernel@sita) (x86_64-linux-gnu-gcc-14 (Ubuntu 14.2.0-4ubuntu2) 14.2.0, GNU ld (GNU Binutils for Ubuntu) 2.43.1) #202409160204 SMP PREEMPT_DYNAMIC Mon Sep 16 02:29:51 UTC 2024

That's a month old. Not exactly "daily". Is this as currently intended or maybe a bug, @vt-alt?

[solardiz]

The listing in https://kernel.ubuntu.com/mainline/daily/ does in fact end with 2024-09-16 right now, and the current directory has that same date.

So the questions are whether this is intentional by Ubuntu or a bug on their end, whether they're going to fix this or not, and whether they have anything newer maybe elsewhere that we could switch to.

This date doesn't look random - it's the day of or right after the 6.11 release.

[vt-alt]

Wiki page for these build is not changed sine 2023 https://wiki.ubuntu.com/Kernel/MainlineBuilds

Also, https://discourse.ubuntu.com/t/kernel-version-selection-for-ubuntu-releases/47007

[vt-alt]

Well, I cannot find 6.12-rc4 anywhere in their kernel git trees (for releases (oracular or plucky). Perhaps, they "just" abandoned creating mainline builds.

[solardiz]

Thank you for investigating this @vt-alt! I think let's wait and see what happens e.g. when 6.12 is released.

[vt-alt]

We can also abandon Ubuntu because of so much hassle with it and switch to Fedora Rawhide — they using mainline kernels too. For example they now have kernel-6.12.0-0.rc4.39.fc42. And it's available in docker as fedora:rawhide. I don't understand (don't remember) why we didn't use Fedora in the first place. Maybe their docker was glitching at the time.

[vt-alt]

I don't understand (don't remember) why we didn't use Fedora in the first place. Maybe their docker was glitching at the time.

Ah because of boot using mkosi. We didn't have docker-boot.yml at the time.

[vt-alt]

IC fedora:rawhide docker is so unreliable, today, for example, it cannot install or upgrade because GPG keys are wrong.

Importing GPG key 0xE99D6AD1:
 Userid     : "Fedora (41) <fedora-41-primary@fedoraproject.org>"
 Fingerprint: 466C F2D8 B60B C305 7AA9 453E D062 2462 E99D 6AD1
 From       : /etc/pki/rpm-gpg/RPM-GPG-KEY-fedora-41-x86_64
Is this ok [y/N]: y
Key imported successfully
Import of key(s) didn't help, wrong key(s)?
Public key for bash-completion-2.13-2.fc41.noarch.rpm is not installed. Failing package is: bash-completion-1:2.13-2.fc41.noarch
 GPG Keys are configured as: file:///etc/pki/rpm-gpg/RPM-GPG-KEY-fedora-rawhide-x86_64, file:///etc/pki/rpm-gpg/RPM-GPG-KEY-fedora-41-x86_64
...
 GPG Keys are configured as: file:///etc/pki/rpm-gpg/RPM-GPG-KEY-fedora-rawhide-x86_64, file:///etc/pki/rpm-gpg/RPM-GPG-KEY-fedora-41-x86_64
The downloaded packages were saved in cache until the next successful transaction.
You can remove cached packages by executing 'dnf clean packages'.
Error: GPG check FAILED
[root@e9295948e301 /]# rpm -E %fedora
40

Also their dnf interface looking suspiciously old. Perhaps, the image is unmaintained.

[vt-alt]

On Docker Hub's fedora:rawhide image (which in logs says Last pushed a month ago):

[root@e9295948e301 /]# ls -lL /etc/os-release
-rw-r--r-- 1 root root 757 Nov  1  2023 /etc/os-release

This is much better (and install works):

$ docker run --rm -it quay.io/fedora/fedora:rawhide
[root@71a9f081fc48 /]# rpm -E %fedora
42
[root@71a9f081fc48 /]# ls -lL /etc/os-release
-rw-r--r-- 1 root root 782 Oct 18 00:00 /etc/os-release

But it still obscure why they maintain their official docker.,io images like this. 🥴