Gentoo template Q&A with developer

User Support General
1

Edit: Renamed thread after speaking with dev

So I’m starting to look into Gentoo since it’s likely to be more secure than Debian and Fedora (AFAIK; I’m not too knowledgeable on this). I’ve noticed that Gentoo has a very DIY philosophy and that this applies to compiling kernels for specific uses. In Qubes OS, is it possible to compile and deploy specific kernels for specific roles?

For example, can I build a sys-net Gentoo that uses a minimal Kernel that basically can only access the ethernet device and pass-on the data?

More generally speaking, what are the limits of customization for GentooVMs on Qubes? Are we limited because Gentoo comes pre-built and configured via qubes-templates-community-testing? If not, is there really any significant difference in security between Gentoo and other available distros?

2 Likes
2

You would be certainly interested in https://github.com/QubesOS/qubes-issues/issues/5212.

Yes it’s possible but I have not not packaged yet the kernel-vm-support in GitHub - QubesOS/qubes-linux-utils: Qubes component: linux-utils but that should be easy. I’ve opened an issue for that gentoo: add kernel-vm-support package · Issue #6193 · QubesOS/qubes-issues · GitHub.

You can use the minimal template or either rebuild the template by yourself in customizing build steps but minimal is already just few steps after stage3 and with very minimal Qubes parts needed. Also, you can even try to use other Portage profiles like the hardened ones but this is untested.

For dev and testing purposes, I’ve implemented the build of each Qubes components. For example, our CI is doing that: qubes-builder/scripts/travis-build-gentoo at master · QubesOS/qubes-builder · GitHub. This is useful if you want to test to build Qubes overlay on top of hardened profiles locally (as we do for every other distributions).

If you need more help on this, maybe it is worth to rename or use another thread for that.

2 Likes
3

Thank you for the speedy reply. If my understanding is correct, the Qubes OS and Gentoo teams are looking to make in-VM kernels a possibility, and this would mean compiling kernels for specific uses is a high possibility in the near future. This sounds great. When it’s done, would the process of installing Gentoo and compiling your own kernel look like this:

  1. Install Gentoo template on dom0
  2. Open Gentoo template and compile customized kernel
  3. Set Gentoo template to use customized kernel
  4. Shut down template to save work
  5. Open Gentoo template settings, switch to in-VM kernel

(Note that I’m not familiar with Gentoo–yet)

I really hope that in the future Qubes ships with a bunch of different kernels each customized (minimized) for specific roles (e.g. one for sys-net, one for sys-usb, etc.). This sounds easier and much more achievable than a sys-net unikernel. Come to think about it, isn’t this already possible with the current version? (e.g. create a sys-net kernel and make it a dom0 update, then select that kernel only for sys-net).

Anyways I’m open to renaming this thread as a general Gentoo Q&A thread. Having a centralized thread raises awareness (via bumps) and invites more people to try it. Let me know if you want me to do that.

2 Likes
4

Yes indeed just as easy as written :smiley:. For other readers, this purpose is because someone wants to use specific Gentoo toolchains and kernels.

Well such purposes of building custom kernels can already be done. Not necessary using in-VM kernel provided by the underlying distribution like you want to do for Gentoo but using our linux-kernel (GitHub - QubesOS/qubes-linux-kernel: Qubes component: linux-kernel) component as working base. Here, you can custom the config-base (it’s the default Fedora one) and config-qubes which is merged after config-base to override Fedora values. Long time ago, Reg Tiangha made a post on devel list (https://groups.google.com/d/msg/qubes-users/yBeUJPwKwHM/CFLgGsyKBAAJ) on how to do such things. It’s a little bit deprecated as things as changed but there is still valid tips. For example, he used to create custom kernels (take a look at -slim/-hard branches GitHub - rtiangha/qubes-linux-kernel: Qubes component: linux-kernel). At some point I could redo such doc/tutorial.

Yes please.

1 Like
5

Done. I added “with developer” at the end to give the thread an extra ‘oomph’–please let me know if you want this changed.

This is useful for when I decide to delve deeper, which I’m not quite ready to do right now. As a non-technical person it took me a while to work up the courage to learn Qubes, and it involved a lot of me coercing myself. This looks much more technical than learning Qubes, but I’ll get around to it eventually.

An updated document isn’t really urgent for me (can’t speak for others), so I think that working on the in-VM kernel option is much better value for your time compared to updating that doc since it also solves the same problem but in a more substantial way.

1 Like
6

Is anyone willing to help me creating the CI integration for Gentoo with builderv2? Basically it means to do two things:

  1. Add jobs in QubesOS/qubes-builder-gentoo similar to other template builders like qubes-builder-fedora

  2. Add jobs in recently moved overlay from fepitre/qubes-gentoo to QubesOS/qubes-gentoo in order to trigger jobs from QubesOS/qubes-builder-gentoo with current PR content.

Gentoo integration in builderv2 exists already, it’s really a matter of addings Gitlab CI jobs.

I would be able to assist on the forum, Matrix or by mail.

I’ve a couple of PR to be merged since a while but as of now, it is only manual builds for me to be done for checking them and I don’t have the time to create the CI jobs part even if it won’t take that much time.

@ludovic ?

3 Likes
7

I was offline for 3 weeks…
For sure I can help as I want a more integrated Gentoo template in the Qubes world.
We can exchange in this forum, in the comments of a github issue or by mail, as you want. Just a thought, maybe by mail is less inclusive for other contributors…

My skills:

  • buildserv2 : I tried 4-5 times to use it but it failed each time, but I used buildserv1 many times.
  • Gitlab CI jobs : I never created Gitlab CI jobs, but I know other CI (Jenkins).
2 Likes
8

@fepitre : I created an issue and added my very very first changes in the first comment.

2 Likes
9

builderv2

to get things in order, I had to call them manually:

  • first get builder sources:
    qb --builder-conf example_configs/gentoo.yml -c builder-gentoo package fetch
  • then build template(s)
    qb --builder-conf example_configs/gentoo.yml template fetch prep build

gentoo-builder

either change gentoo.yml to use https://github.com/saces/qubes-builder-gentoo (or the pr #13 url) or apply the patches manually in artifacts/sources/builder-gentoo after package fetch

gentoo (patch content)

  • gpg key update and feature change in gpg 2.4
  • profile switch 17 → 23

old template

if you want to upgrade the old template by yourself you find maybe useful notes here: https://codeberg.org/saces/qmbadmin/src/branch/main/gentoo.md

template names

I would recommend to change the template names to something like gentoo-23[-flavour] before release. this would allow better profile switch handling next time :slight_smile:

2 Likes
10

That makes sense. We could do that indeed for further builds.

11

with https://github.com/QubesOS/qubes-gentoo/pull/36 applied the gentoo-minimal build was succesful.

the overlay repos used for build: https://codeberg.org/saces/qubes-gentoo-23

1 Like
12

I have a working gentoo template now \o/

this template is named gentoo-minimal
installing it will overwrite an existing one.

to get the build done i turned off gpg signature checking. this will be push -f’ed away later. (i need to figure out stuff first;)

the new profile 23 is systemd based and brings a lot of new … dependencies.
some are already off, still a bit bloated.
the old template is still working, so i did not update the qubes packages (yet)

anyways, this can be improved inside a running profile/23/systemd template :wink:

quick howto:

get builderv2
edit example-configs/gentoo.yml:

 components:
   - builder-gentoo:
       packages: False
-      url: https://github.com/QubesOS/qubes-builder-gentoo
+      url: https://github.com/saces/qubes-builder-gentoo
       maintainers:

run:

./qb --verbose --debug --builder-conf example-configs/gentoo.yml -c builder-gentoo package fetch
./qb --verbose --debug --builder-conf example-configs/gentoo.yml -t gentoo-minimal template fetch
./qb --verbose --debug --builder-conf example-configs/gentoo.yml -t gentoo-minimal template prep
./qb --verbose --debug --builder-conf example-configs/gentoo.yml -t gentoo-minimal template build

find rpm in artifacts/templates/rpm/

urls

the builder: https://github.com/saces/qubes-builder-gentoo
used overlay: https://codeberg.org/saces/qubes-gentoo-23
my private build: https://codeberg.org/saces/-/packages/rpm/qubes-template-gentoo-minimal/4.2.0-202509212347

3 Likes
13

Hello, I am having trouble with gpg verification in the fetch phase for the builder

Steps to reproduce

  • Edit example-configs/gentoo.yml to look like
components:
 - builder-gentoo:
     packages: False
     url: https://github.com/saces/qubes-builder-gentoo
     maintainers:
  • run
    ./qb --verbose --debug --builder-conf example-configs/gentoo.yml -c builder-gentoo package fetch

and the resulting log

2025-11-17 09:24:16 [qb.fetch.builder-gentoo.fetch] copy-in (cmd): docker cp /tmp/tmpor45gp94/. 51c55856d12c48547e7bdcf549d6da42d01871cef440a9b1c6094ebb4f2e6abc:/
2025-11-17 09:24:17 [qb.fetch.builder-gentoo.fetch] copy-in (cmd): docker cp /tmp/tmpor45gp94/. 51c55856d12c48547e7bdcf549d6da42d01871cef440a9b1c6094ebb4f2e6abc:/builder
2025-11-17 09:24:17 [qb.fetch.builder-gentoo.fetch] copy-in (cmd): docker cp /tmp/tmpor45gp94/. 51c55856d12c48547e7bdcf549d6da42d01871cef440a9b1c6094ebb4f2e6abc:/builder/plugins
2025-11-17 09:24:17 [qb.fetch.builder-gentoo.fetch] copy-in (cmd): docker cp /home/user/qubes-builderv2/qubesbuilder/plugins/fetch 51c55856d12c48547e7bdcf549d6da42d01871cef440a9b1c6094ebb4f2e6abc:/builder/plugins
2025-11-17 09:24:17 [qb.fetch.builder-gentoo.fetch] Using executor docker:51c55856d12c to run 'sudo mkdir -p -- /builder /builder/build /builder/plugins /builder/distfiles&&sudo chown -R -- user:user /builder&&cd /builder&&/builder/plugins/fetch/scripts/get-and-verify-source.py https://github.com/saces/qubes-builder-gentoo /builder/builder-gentoo /builder/keyring /builder/plugins/fetch/keys --git-branch main --minimum-distinct-maintainers 1'.
2025-11-17 09:24:22 [qb.fetch.builder-gentoo.fetch] --> Verifying tags...
2025-11-17 09:24:22 [qb.fetch.builder-gentoo.fetch] ---> No tag pointing at 25525052cda737d2a9adb779d84035b73eb555a5
2025-11-17 09:24:22 [qb.fetch.builder-gentoo.fetch] ERROR: CalledProcessError(1, ['git', '-c', 'gpg.program=/usr/bin/gpg', '-c', 'gpg.minTrustLevel=fully', 'verify-commit', '--raw', '--', '25525052cda737d2a9adb779d84035b73eb555a5']); stderr: [GNUPG:] NEWSIG
2025-11-17 09:24:22 [qb.fetch.builder-gentoo.fetch] [GNUPG:] ERRSIG 2D1B511919F86901 22 8 00 1758556743 9 8D69A04F7F0602B183037FA22D1B511919F86901
2025-11-17 09:24:22 [qb.fetch.builder-gentoo.fetch] [GNUPG:] NO_PUBKEY 2D1B511919F86901
2025-11-17 09:24:22 [qb.fetch.builder-gentoo.fetch] [GNUPG:] FAILURE gpg-exit 33554433
2025-11-17 09:24:22 [qb.fetch.builder-gentoo.fetch] 
2025-11-17 09:24:22 [qb.fetch.builder-gentoo.fetch] ---> Invalid commit 25525052cda737d2a9adb779d84035b73eb555a5.