I’m trying to get Qubes to build using the Qubes executor. As I haven’t managed to get any successful build yet, I’m trying to follow the README strictly, and building on fresh vms. I’m using examples/qubes-os-r4.2.yml unchanged from the current main (6942fa).
Somehow I already failed, since my build qube has a hostname of fedora rather than the qube name, which causes qubes/executors/qubes.py to break (but hacking that works). (Later, found the cause: clone a qube from fedora-39-xfce and include an underscore in the name, and its hostname will be fedora. That’s unexpected. Fixing this didn’t change the following.)
Now I have qb package fetch failing trying to verify python-fido2, because the signing key 20EE325B86A81BCBD3E56798F04367096FBA95E8 is bad (expired in 2020). I can also see this in the build logs for fedora and debian last month, but I’ve no other context. It recurs if I remove artifacts/sources and re-run.
Same error with qubes-os-main.yml
Chasing down the individual error would be good, but I’m mainly posting because I’m confused about why I’m having problems. It looks like the automated CI runs several times a day, and I’m guessing there are other users here running builds daily, plus the core team. The docs look clear to me and there doesn’t seem to be much room to mess things up. I also hit several other obstacles a couple of weeks ago running the Docker executor (specifics not recorded, but not related to key signing). I haven’t seen much on this forum about builds breaking.
So I think I’m looking for more context. Is running off main recommended, or is there some baseline that might be more reliable? Are there big differences between a local build and the automated CI? Are both executors stable and supported? Is there another place where build issues are discussed?
Same error with a fresh build a week later. I’ve verified it also fails the same way with the docker executor.
This is a problem for me participating on the audit project. There, I’m interested in lowering unnecessary barriers to entry to get more people hands-on. Running into difficulties with the default build, and not getting responses here, conflicts with that.
List of steps
In a new template cloned from stock fedora-39-xfce, clone qubes-builderv2 under /opt
Copy qubes-os-r4.2.yml to builder.yml
Install packages from dependencies-fedora.txt
Install mkmetalink using the qubes-infrastructure-mirrors readme and move to /usr/bin
Do executor-specific stuff
In a new qube based on the new template, run ./tools/generate-container-image.sh docker fedora-39-x86_64 and add the default user to the docker group
I have the same issue on Fedora 40 (outside Qubes OS). I removed python-fido2 from the dependency list, but then I encountered the same issue with lvm2. Removing both of them makes it work but I guess lvm2 is mandatory.
Fetch and Prep stages work but I then have an error on Build, so same, not able to build an ISO for now.
I’m using Podman because it seems to work better than Docker on Fedora.
Also the doc gives the example with a Fedora 36 Docker image but it’s not working anymore with Fedora 40 host. Not specifying mock configuration allows to build latest.
I’m not surprised, last year I’ve been working with the builder and there were also similar issues with wrong config files. It wasn’t difficult to fix but I guess devs are using their own configs and we need more contributors.
sqv --keyring /tmp/tmp.Jzo3DW0BTO/keyring /home/user/Qubes/qubes-builderv2/artifacts/tmp/tmp159fgf5n/untrusted_fido2-1.1.2.tar.gz.sig /home/user/Qubes/qubes-builderv2/artifacts/tmp/tmp159fgf5n/untrusted_fido2-1.1.2.tar.gz
Signing key on 20EE325B86A81BCBD3E56798F04367096FBA95E8 is bad:
The primary key is not live
because: Expired on 2020-05-01T11:07:16Z
I guess devs are using their own configs and we need more contributors.
My reasons for assuming upfront that the build is more mature were:
There’s a detailed developer section on the front page of the website documentation.
There’s a testing community.
There’s a daily CI build (I can’t view the GitLab page, but I can see the code and the logs. At a glance, the CI code appears to do more than simply wrap the builderv2 code.).
I didn’t look deeply, but couldn’t find a recent change to explain this. Also, why the CI build hit this failure once in April but not since.
But replacing the key (mv ~/Downloads/D501A478440AE2FD130A1BE8B9112431E509039F.asc artifacts/sources/lvm2/mcsontos-key.asc) does not work, there is this issue:
Signing key on D501A478440AE2FD130A1BE8B9112431E509039F is not bound:
No binding signature at time 2020-03-26T11:26:45Z
What I described above make Fetch and Prep stages work, but then Build fails with this:
mknod: /builder/pbuilder/build/37/test-dev-null: Operation not permitted
E: Cannot install into target '/builder/pbuilder/build/37' mounted with noexec or nodev
E: debootstrap failed
How far into the build is this? I have a ./qb package fetch prep build 9 hours in currently after disabling sqv. (this is not the furthest I’ve got, unfortunately)
I also wonder if there’s anything that can be done about network resilience - I often get github network failures over whonix, and I think my ISP blocks archive.org, so I only get stability over VPN right now. Not ideal.
I get the error just after running the build script.
I had similar issues with network also, I agree, but there is also an option not to refetch sources: skip-git-fetch: true in the builder.yml, to save time on the next run.
Oh yeah, it was more like 3-4 hours for me but I’m not running it on Qubes but on a Fedora 40 install so much faster. The 4.2 config file also contains way too many stuff for testing, I started to create one with the bare minimum
Ah that’s useful. I’ll consider paring down the component list after getting one successful build with everything. Did I miss some docs for building for testing somewhere?
I don’t see anything on the doc about testing configs, but for example it’s not necessary to build other DE than XFCE if you want to test a basic install. Separate packages by categories like “Base”, “KDE”, or “Full” for example will be useful later to create groups in Anaconda and have more choice during install
