How outdated are dom0 kernel build instructions?

Documentation | Qubes OS points to a 4yo email as “How to compile kernels for dom0”. Could it be time to migrate this into the doc website, so it can be adjusted to current reality ?

  • it points to a source repo that did not see a commit since 2017
  • which should probably be referenced instead has stable-5.10 as latest branch, whereas there are 5.12 and 5.13 kernels in qubes-testing
  • it directs the user to save the .config as config, whereas a cursory glance seems to reveal that today the config is split between config-base and config-qubes

… and when launching the advertised command:

[user@fedora32-qubes-build qubes-linux-kernel]$ make rpms
Makefile:65: *** "You can not run this Makefile without having FETCH_CMD defined".  Stop.

[user@fedora32-qubes-build qubes-linux-kernel]$ make rpms FETCH_CMD=wget
make: *** No rule to make target 'rpms'.  Stop.

[user@fedora32-qubes-build qubes-linux-kernel]$ make help
Makefile:65: *** "You can not run this Makefile without having FETCH_CMD defined".  Stop.

[user@fedora32-qubes-build qubes-linux-kernel]$ make help FETCH_CMD=wget
Usage: make <target>

get-sources      Download kernel sources from

/bin/sh: -c: line 0: unexpected EOF while looking for matching `"'
/bin/sh: -c: line 1: syntax error: unexpected end of file
make: *** [Makefile:135: help] Error 1

Did you take a look at this?

Yes I know about it. But if the way described on the main doc page is not supported any more, we will surely want to adjust the doc - I can even propose a patch. If it should still be possible to build the kernel from just this repo, then maybe someone using it that way could propose a patch. Let’s just not let the doc rot :slight_smile:

Doc PRs definitely welcome for this. I don’t know enough to update this page myself.

1 Like

I would appreciate a patch for building dom0 kernels from the newer QubesOS/qubes-linux-kernel repository very much, since i tried it a couple of days ago and failed.

What would be useful first is some dev documentation for the custom build system used in Qubes. I could only find user-level doc, ie. “how to build existing packages”, not “how to write/understand a qubes package”.
This is IMHO a limiting factor for onboarding more devs, and as a side effect does not help us getting sufficiently up to speed to understand what should be done here and update this page.

As for first building the kernel with qubes-builder, with the info I had gathered 2 months ago, here is what I get:

[user@fedora32-qubes-build qubes-builder]$ make qubes COMPONENTS=linux-kernel
Package python3-devel-3.8.10-1.fc32.x86_64 is already installed.
No matching package to install: 'qubes-kernel-vm-support'
Not all dependencies satisfied
Error: Some packages could not be found.
make[2]: *** [/home/user/qubes-builder/qubes-src/builder-rpm/Makefile-legacy.rpmbuilder:52: dist-build-dep.spec] Error 1

There seems to be a dependency missing, which brings us to my point: we first need enough documentation so a newcomer can add a missing dep without hours of digging.


Looking around a bit, this rpm comes from linux-utils, so we can build it beforehand:

[user@fedora32-qubes-build qubes-builder2]$ make linux-utils-dom0
Currently installed dependencies:
make[1]: Entering directory '/home/user/qubes-builder2'
git -C /home/user/qubes-builder2/chroot-dom0-fc32/home/user/qubes-src/linux-utils clean -f -d -X
/home/user/qubes-builder2/scripts/create-archive /home/user/qubes-builder2/chroot-dom0-fc32/home/user/qubes-src/linux-utils qubes-utils-4.1.15.tar.gz
~/qubes-builder2/chroot-dom0-fc32/home/user/qubes-src/linux-utils ~/qubes-builder2
-> Building linux-utils (rpm_spec/qubes-utils.spec) for fc32 dom0 (logfile: build-logs/linux-utils-dom0-fc32.log)
--> Done:
-> Building linux-utils (rpm_spec/qubes-kernel-vm-support.spec) for fc32 dom0 (logfile: build-logs/linux-utils-dom0-fc32.log)
--> Done:
make[1]: Leaving directory '/home/user/qubes-builder2'

[user@fedora32-qubes-build qubes-builder2]$ make linux-kernel-dom0
Package qubes-kernel-vm-support-4.1.15-1.fc32.x86_64.rpm is not signed
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
make[2]: *** [/home/user/qubes-builder2/qubes-src/builder-rpm/Makefile-legacy.rpmbuilder:52: dist-build-dep.spec] Error 1

so… that would look like the way to go… except that even with NO_SIGN=0 and a ~/.rpmmacros configured as documented (reproduced below), the packages still are not signed (and we are not told about it).


First of all, it appears that the reverse of NO_SIGN=1 is not NO_SIGN=0 but “NO_SIGN=”, ie. empty. That only will allow the COMPONENTS_TO_SIGN variable to be non-empty.

Then make sign.dom0.fc32.linux-utils will get the generated rpms signed. But in my case the error becomes:

Public key for qubes-kernel-vm-support-4.1.15-1.fc32.x86_64.rpm is not installed

Digging the docs the only reference I find to keyring importing is about keys used to verify signed commits. All I could find is copying by exported key into the chroot and importing it myself:

sudo chroot chroot-dom0-fc32/ rpm --import /yann-qubes-gpg.asc

… and now at last my kernel gets to build.

Is there some other/cleaner way of achieving import of the key ? How are you core devs doing in everyday life ? It would look like a job for a specifc keyring, eg. keyrings/rpmimport, so this does not have to be redone manually for each new chroot ?
… especially as having to do this is especially annoying when trying to streamline the build instructions.

Please check, I did succeed in building a kernel with those instructions (though the ones for full build just won’t work, for a reason that will probably become obvious when old-timers will point to the problem).

1 Like

I’m inclined to agree, but I’m afraid I know even less about that. Perhaps @Demi might be able to help here?

Hi, do you mind telling me what commands you used to compile a dom0 kernel for R4.1 current-testing?
I tried fc32 & fc33 templates, also the setup script and manually editing builder.conf(example) but I still get different errors when building.

@Johnboy my draft MR should help, but I agree it’s not immediate to find the modified page, here it is. Read through the generic part first (although it does not work yet for the purpose of building everything), and the kernel-specific part to get the small set of commands to be replaced - the generic setup, ie. mostly setting the signing key, is common to both cases.

Edit: updated link with an hopefully-better version

1 Like