Debian/Fedora build-script not working under Qubes OS Debian/Fedora VMs

[dmn86q]

What is happening?

I'm trying to build Linux Heads locally but both build-scripts for either Debian or Fedora through an error at me. I'm using Qubes OS 4.1 on a Lenovo T440p (i7/16GB RAM) flashed with coreboot, using Conor's Guide but have not flashed heads so far. I installed all dependencies necessary for a build mentioned under: General-Building

On a debian vm the build fails, because of a checksum mismatch:

On the fedora side of things, the cross-compiler fails the build step. There is no package available when typing sudo dnf install cross-gcc as found in the circle-ci list of installed packages:

On Qubes OS you cannot build the Archlinux-Template either, since the build-script fails on building something with core-libvirt needed.

Questions and Assumptions

1. Is the debian checksum mismatch of zlib a debian issue, a Qubes one, or one heads should take care of?
2. The cross-gcc package is not there anymore? Does the build-script need rewriting or do the fedora folks have an issue here?
3. The Archlinux template failing gives me the same assumption than the fedora one - script rewriting or their's?

Why all this?

I stumbled across those errors, since I bought two refurbished Lenovo T440p last months, to use them with Linux Heads, Coreboot and HOTP. While I was able to install the latest heads build from circle-ci via CH341_a flash-programmer, I encountered a problem booting .iso files from a usb-drive. The gpg-verification of Qubes OS works, but I do not get any screen output, since i915 module is not present. insmod answers: No such file or directory, when trying to load the module manually. Another user reported the same problem here: https://github.com/osresearch/heads/issues/702

It took me to building heads locally myself, with a t440p-hotp-maximized.config yet to be edited, but I'm not getting the build-environment to build a default build in the first place.

The second approach was to build an Arch Linux Template, build arch-linux in a chroot environment and use the build artifacts from circle-ci, i.e. the initrd.cpio provided. I am not sure how to build arch-linux with a different initrd.img in place, so help is greatly appreciated. If I am misled by the assumption to build an .iso from the chroot environment and add a different initrd.img would be a smart idea, feel free to stop me. But again, the build environment is stopping me from trying this in the first place.

I feel a little lost, which path to persuade from here. Is the approach of trying to build heads locally and Debugging the t440p-hotp-maximized.config and coreboot.config the way to go? Or shall I try to build an archlinux.iso with the initrd.cpio from circle-ci included? Or is there any other way of handling this issue?

[tlaurion]

@dmn86q hello there, first things first, thanks for having taken the time to file this issue.

The cross-gcc package is not there anymore? Does the build-script need rewriting or do the fedora folks have an issue here?

I will edit the wiki page for building since as of today, the only host OS fully supported to build Heads is Debian.
Last patches backported fix needed for linux to build on debian-12, so debian-11 and debian-12 based OS should work as builders. It is planned to depend on Nix layer for reproducibility, but this is not done yet. The idea here is to be able to run the same commands on any OS supported to build Heads repruducibily for a specific commit for a specific board.

Is the debian checksum mismatch of zlib a debian issue, a Qubes one, or one heads should take care of?

I could not reproduce your zlib issue.

user@heads-tests-deb12:~/heads$ rm packages/x86/zlib-1.2.11.tar.gz
user@heads-tests-deb12:~/heads$ make BOARD=qemu-coreboot-whiptail-tpm1 zlib
2023-05-26 08:46:07-04:00 WGET https://zlib.net/fossils/zlib-1.2.11.tar.gz
--2023-05-26 08:46:07--  https://zlib.net/fossils/zlib-1.2.11.tar.gz
Resolving zlib.net (zlib.net)... 85.187.148.2
Connecting to zlib.net (zlib.net)|85.187.148.2|:443... connected.
HTTP request sent, awaiting response... 200 OK
Length: 607698 (593K) [application/x-gzip]
Saving to: ‘/home/user/heads/packages/x86/zlib-1.2.11.tar.gz.tmp’

/home/user/heads/packages/x86/zlib-1. 100%[=======================================================================>] 593.46K   717KB/s    in 0.8s    

2023-05-26 08:46:09 (717 KB/s) - ‘/home/user/heads/packages/x86/zlib-1.2.11.tar.gz.tmp’ saved [607698/607698]
user@heads-tests-deb12:~/heads$ sha256sum packages/x86/zlib-1.2.11.tar.gz
c3e5e9fdd5004dcb542feda5ee4f0ff0744628baf8ed2dd5d66f8ca1197cb1a1  packages/x86/zlib-1.2.11.tar.gz
user@heads-tests-deb12:~/heads$ grep hash modules/zlib 
zlib_hash := c3e5e9fdd5004dcb542feda5ee4f0ff0744628baf8ed2dd5d66f8ca1197cb1a1

Simply remove zlib tarball and try again, seems like some weird internet hiccup happened for you?

The Archlinux template failing gives me the same assumption than the fedora one - script rewriting or their's?

Unfortunately, i'm not an Archlinux user and cannot help and building iso for Archlinux would fall under Archlinux support channels.

The gpg-verification of Qubes OS works, but I do not get any screen output, since i915 module is not present. insmod answers: No such file or directory, when trying to load the module manually. Another user reported the same problem here: #702

Issue #702 is specific about Archlinux and i915 not being present in the initrd, pointing to instructions needed to add it manually. It is present under QubesOS and works on xx30/xx20 out of the box. The kexec call takes a little while though prior of loading the next kernel, loading the initrd and from there, loading i915+drm drivers which then and only take ownership of the console to show content on the screen. If you are building from master, that one for t440p and QuebesOS would deserve a specific issue of its own. Can I ask you which version of the rom you have flashed? (System Info would answer that question easily: that would be the X in gXXXXXXX):

The second approach was to build an Arch Linux Template, build arch-linux in a chroot environment and use the build artifacts from circle-ci, i.e. the initrd.cpio provided. I am not sure how to build arch-linux with a different initrd.img in place, so help is greatly appreciated. If I am misled by the assumption to build an .iso from the chroot environment and add a different initrd.img would be a smart idea, feel free to stop me. But again, the build environment is stopping me from trying this in the first place.
I feel a little lost, which path to persuade from here. Is the approach of trying to build heads locally and Debugging the t440p-hotp-maximized.config and coreboot.config the way to go? Or shall I try to build an archlinux.iso with the initrd.cpio from circle-ci included? Or is there any other way of handling this issue?

I'm a bit confused on the goals here. If I understand correctly, you are trying to install Archlinux, but currently using Qubes. There is an Archlinux template usable into QubesOS. If you want to install Archlinux on bare metal, #702 would need to be invested and that one should be followed. Building a new ISO might be the way to go, but as far I as understand the t440p board status, i915+drm drivers inside of Heads should be able to boot into Archlinux as of today, and prior of installing the OS, you would need to inform that i915 is desired to be packed in initrd, for which pointers are given there to do so. Otherewise I thought that QubesOS was tested prior of merging #1282

Then the board config was updated to include hacks to kexec + i915+drm under #1378 (comment) but not with QubesOS directly, though. If not working, that would deserve also a seperate issue, since QubesOS should be first class support for Heads and asking other board owners to confirm issue would provide confirmation of issue.

Will point https://osresearch.net/general-building/ commit to here. Let me know if this clarifies things, and close this issue accordinlgy if it does.

[tlaurion]

Closing this issue as duplicate of others. General building instructions updated per linked commit above.
Please do not hesitate to tag me if you think this issue should be reopened @dmn86q