TL;DR

If you are interested in building alternate kernel packages or kernel module packages for Fedora, or if you’re interested in testing alternate kernels or kernel modules on Fedora, let’s chat.

Fedora’s kernel works well if you don’t need out of tree drivers

When I look through user forums, one of the problems I see described most frequently is a blank screen on boot. Sometimes this is a first-time setup and the user hasn’t followed all of the documented installation steps, or they haven’t followed the correct list of steps. (In theory, this should be a one-click operation for users that have enabled third party repos, but the last time I checked that doesn’t actually work because rpmfusion only provides AppStream data for their primary repos, not for the NVIDIA driver repo that users can enable as a third party repo.) Sometimes they’ve rebooted the system without waiting for the invisible background process of building the display driver module and the kernel initramfs to complete. Sometimes it fails and there’s simply no indication to the system’s user why. Maybe the disk ran out of space.

Whatever the cause of the problem, I think that this is one of the top reasons that Fedora is often not rated as a “beginner-friendly” distribution.

Fedora’s policies prohibit alternate kernels, and packaging kernel modules. I suspect that this is driven at least in part by requirements imposed by the agreements under which their Secure Boot signing keys are signed by the UEFI 3rd party signing CA. That’s all perfectly reasonable, but it’s also a barrier to any kind of experimentation or improvement.

I am convinced that Fedora users need pre-built kernel modules. As an SRE, I believe that reliable systems build code, test the build, and then deploy the tested build. Systems like akmods and dkms deploy the code first, then build it in place and “test in prod.” It is inevitable that such systems will fail regularly.

The Nova driver will eventually resolve this problem for most NVIDIA users, but there will continue to be users who want out of tree drivers for ZFS, VirtualBox, WiFi drivers that haven’t merged yet, etc.

Ready-to-run signing infrastructure

There’s no shortage of information about how to sign code with pesign, but they’re not always easy to use. Some guides don’t actually work on contemporary releases. Some guides are hardware specific.

The best way to promote a process is to make it as easy as possible. If a process can simply be “fork and build”, it’s much more likely to be adopted and deployed. I’ve developed a Terraform project that you can fork and build to deploy a VPC in AWS in which a forgejo-runner has an HSM with code signing certificates. Users who install the signing certificate in their MOK can use kernels and kernel modules produced on this infrastructure.

Below, you can find the Terraform project, a kernel rpm, a kernel module rpm, an Atomic desktop configuration, and an Atomic desktop container image, all of which can serve as starting points for further development:

If you’ve installed an Atomic desktop, you can try the Fedora Remix:

sudo rpm-ostree rebase ostree-unverified-image:registry:quay.io/gordonmessmer/atomic-desktop/silverblue:43.20260411.0

Various guides to signing code for Secure Boot