Early last year I bought a Librem 14 laptop with Pureboot + QubesOS installed.
Last week, I updated QubesOS to 4.2.
When I reboot I see a Boot Hash Mismatch showing these files:
I wasn’t aware that QubesOS upgrade will change the boot firmware.
Once I started looking at the boot directory, I also don’t see any Heads files/directories either.
Under system info, i see this:
Kernel: Linux 6.1.8-PureBoot
Is the above boot hash mismatch to be expected ?
Very likely yes. If you apply an update and the update changes something in
/boot then the warning is legitimate but nothing to be worried about.
How did you proceed? New install from live-USB or dist-upgrade from within Qubes4.1? The outcome would be different for one or the other.
I recently did a dist-upgrade on my 4.1 setup and really had no problem (although the procedure is long and complicated, but well explained in pertaining docs).
In no way would the firmware have changed if installing or updating a target system - but the /boot volume would have a lot of changes and hence must be signed again (and probably again after rebooting Qubes and updating packages to latest versions)
I followed the directions on the QubesOS docs and installed the 4.2 on a USB. And then proceeded to install from the OS Boot Menu on my laptop.
That explains why your /boot partition would lack HEADS files.
After a clean install, there would not be any and you need to refresh hotp and then sign all the files.
If the HEADS files have been deleted by the QubesOS upgrade, what payload is coreboot using ?
If you are using Pureboot, the coreboot payload is HEADS and it is part of the firmware (in fact, the last stage of the coreboot run)
When you install a new OS, it will create a new /boot partition, but none of the files that HEADS uses will be there yet. You have to do the process of sealing an hotp secret again and then sign the new /boot partition.
All the files needed by HEADS will reappear in your /boot - those files are needed for HEADS to confirm integrity of the firmware and integrity + authenticity of the boot partition and all the important binaries about to be loaded before transfering control to the OS via kexec (bypassing bootloaders and bootkit problems)
*when I say authenticity here, I mean “as far as you are trusting your distribution (PureOS, QubesOS, Debian, Fedora…) to provide you with known-good up-to-date uncompromised kernel/hypervisor and other binaries or config files in /boot”.
But in the end, you have to trust somebody, if you want to run any OS at all.
So HEADS does not guarantee the authenticity of what’s in you /boot volume, but it does check for integrity of the partition - meaning it is still in the same state as when you last signed it.
If you have some interest for how this all works and what all those HEADS files in /boot are for, there is a more detailed explanation in the OSResearch wiki at Configuring Boot Options | Heads - Wiki