PureBoot/Heads doc outdated

From the doc: https://docs.puri.sm/PureBoot/Heads/User_Manual.html#heads-beta-installation-instructions

A Librem Laptop with a TPM chip running PureOS (sorry Qubes users, the dom0 flashrom is too old)

Just want to report that I just did it and it is working fine, no issue on the current version of Qubes OS to flash it from dom0

Build the rom / tools / and everything needed in a AppVM, then copy the result to dom0, then flash
( but needed to modify a bit the coreboot_util.sh script )

On the same page, in section Perform initial Heads configuration, the last paragraph reads:

Note that during the process of setting up the default boot option, Heads will ask you whether you want to store your LUKS password in the TPM. This is not currently a supported option so stick to the default answer, no, when prompted. You should then boot into your OS.

I successfully installed PureBoot today on my Librem15v4 with PureOS, and at this stage Heads did not ask me whether to store your LUKS password in the TPM. Is this outdated, or is it a peculiarity of my installation process or setup?

I built both Coreboot and Coreboot+Heads images from source using the instructions on the same page, and I already started a couple of months ago to use my Librem key at boot for main internal storage LUKS key unlocking.

I have been trying to get Qubes installed using Pureboot/Heads but when I install Qubes it does not have the ability to recognise the network or USB’s and ultimately it will not launch an VM. I am curious if you installed Qubes first, then flashed the BIOS to Pureboot, or the other way around. I’d really like to get the Librem Key working with Pureboot and Heads - which it sounds like you both have!

Yes I use Librem Key + Pureboot + Heads + Qubes

-> Installed Qubes
-> Flashed the BIOS to have HEADS
-> (reinstalled Qubes but another reason, so probably not necessary)

But be sure to use the latest kernel available https://www.qubes-os.org/doc/software-update-dom0/#kernel-upgrade

That is awesome, thanks @neowutran! I have just flashed my BIOS back to SeaBIOS, and will try to get Qubes going, then reflash the BIOS to HEADS…will let you know :wink:

HOw did this work for you? Did you get Qubes installed with Pureboot? Did you have to go back to SeaBios first?

I tried this and have had mixed results, so hoping someone can give me some pointers.

  1. I have the Librem 15 v4
  2. I setup my Librem Key manually (using PureOS and following the Librem key instructions for generating new keys and applying them to the key) and make sure i backed up the .gnupg folder and also exported the keys to a USB drive
  3. While still in PureOS I did a manual build of the pureboot rom and copied it to a USB. I also did a manual build of coreboot and copied that as well in case i needed to switch back.
  4. I installed Qubes 4.0.4 (wiping out PureOS)
  5. Qubes boots fine and the Atheros wifi works without a problem. I’m able to update dom0 and i updated to the latest testing kernel using
    sudo qubes-dom0-update --enablerepo=qubes-dom0-current-testing kernel kernel-qubes-vm
  6. I even take the opportunity to upgrade the Fedora 32 template VM to Fedora 33 (added new and removed 32)
  7. I set the new kernel as the default kernel in qubes-prefs and made sure specifically the sys-net, sys-whonix and sys-firewall VMs were set to use that kernel (version was 5.11.1)
  8. I rebooted using PureOS liveusb and used the livecd to flash the pureboot rom
  9. After flashing, i removed PureOS live USB and i’m prompted to perform an OEM factory reset since the bios was recently flashed. I clicked ok, and it wiped out my keys. Not a big deal, i just used the recovery prompt to reapply the keys i generated previously (since i wanted to use a key that i had a backup of).
  10. Now that my gpg are back on the libremkey, I continued with the OEM reset and had the pub key added to the bios and subsequently signed all the files in /boot with the key.
  11. I reset the TPM and generated new HOTP/TOTP
  12. After reboot, my Librem Key and Heads worked like a charm and i was prompted to set a default boot entry in the bio. I set it to Qubes, and qubes successfully booted, and everything was working fine (at first) to include the Wireless card. I was able to see sys-net, sys-whonix and sys-firewall all started with no problem and i was able to add some apps to my VMs.
  13. I changed / updated some settings (e.g. DPI in dom0, scaling factor in personal/work VMs, etc…) and then i rebooted.
  14. After the next reboot (and every subsequent one) wifi is no longer working and the sys-net, sys-whonix, sys-firewall did not automatically start and when i tried to start them, i get the following: error invalid argument could not find capabilities for arch=x86_64

I retried all the steps above thinking maybe something in current-testing caused it to fail after the second reboot, and when i reinstalled cubes, i had it use the kernel-latest from the current instead of current-testing, however this did not work at all (not even for a single boot).

If I simply reflash coreboot/Seabios back to the rom, and let the system boot into Qubes, Wifi works.

Any help would be much appreciated.

@jeremiahmoree
Don’t remember the exact detail, received my librem 13v4, remove PureOS and installed QubesOS instead. Then flashed the thing to have HEADS from QubesOS (adapted the script and ran it from dom0)

@dciphr
Did the same things, however I am using/testing the Qubes R4.1 (Alpha/testing) on my librem 13v4. I remember that I had this issue once, long ago, before beginning to test the R4.1. Either try to get more logs / try to check the pci passthrou devices config ( strict reset ? ), or try to test R4.1