NitroPad v54 dasharo heads cannot sign new files on reboot after Xen upgrade

NitroPad, NitroPC
1

I’m on Qubes 4.3, I upgraded all the things, including dom0, and rebooted. I paid attention to the Linux kernel versions that were being changed and noticed that the kernel I am using (6.19.x) was not updated, rather other older and newer versions were changed. As expected, I get an “ERROR: Boot Hash Mismatch 30 files failed the verification process! This could indicate a compromise! Hit OK to review the list of files. Type “q” to exit the list and return.” All well and good, I choose “OK”, review the list of files, and it looks about as expected. Type “q”. As expected I now have the option to “Investigate Discrepancies –>”, to “Update checksums now”, or to “Return to main menu”.

When I choose “Update checksums now” it gives “ERROR Failed to update checksums / sign default config” and I can then choose “OK”. If I choose OK I am back to the three options before, so I choose “Investigate Discrepancies –>” and it says “Integrity Investigation Integrity mismatches were detected. Detached signature on /boot/kexec.sig verified successfully. Choose an action:” and then offers “Show mismatch details –>”, “Show detached signed output –>”, “Update checksums now”, “Drop to recovery shell (view discrepancies)”, or “Continue”, so again I choose “Update checksums now”, and it gives me “Update Checksums and sign all files in /boot You have chosen to update the checksums … Do you want to continue?” I choose “Yes” and again “ERROR Failed to update checksums / sign default config” Why?

I instead choose “Continue” and then go to Main Menu, “Options –>” then “Update checksums and sign all files in /boot”, same story as before: “ERROR failed to update checksums / sign default config.” Suppose I wish to boot so I go back to “Options –>” then “Boot Options –>” then “Show OS boot menu” then it says “ERROR: Boot Hash Mismatch 30 files failed the verification process! This could indicate a compromise! Hit OK to review the list of files. Type “q” to exit the list and return.” Same for choosing “Default Boot” (I suppose as expected)

Oddly, one of these times it said 61 files, most times it says 30 files.

I see a little message on the console when it flashes between the heads menus. So I drop to the recovery shell to see that message. Here’s the error message on the console right before the recovery shell prompt:

“ >> Signing Dasharo boot hashes under /boot

sha256sum: can’t open ‘./xen-4.19.4.gz’: No such file or directory”

When I run ls /boot I in fact do not see xen-4.19.4.gz because it has apparently been replaced with xen-4.19.5.gz which I do see. Why would it need xen-4.19.4.gz when I am trying to update my boot hashes? How do I get out of this mess?

2

When I look at the list of changed/new files, it does show “./xen-4.19.4.gz” in the first part of the list and then later “(new) ./xen-4.19.5.gz”, so does that imply that it is going to look for those “changed” files (the first part of the list) even if the “change” is “deleted”?

3

Oh, and because I didn’t provide it before:

System Info

FW_VER: Dasharo (coreboot+heads) v0.9.1

EC_VER: 2026-03-12_d198b64

Kernel: Linux 6.1.8-Dasharo

CPU: Intel Core Ultra 7 155H

Microcode: 0x25

And yes, an unsafe boot seems to actually boot. But I’d like to update the sums.

4

I also notice that the (old, deleted) xen-4.19.4.gz appears in kexec_default_hashes.txt, perhaps that is part of the issue, looking back at the message “sign default config” is part of it. So perhaps it is because the xen kernel in my default config was removed.

5

Suppose I go ahead with the unsafe boot (the Linux kernel 6.19.14 I use has not changed, and the 4.19.5 xen kernel is legitimately fresh, machine has been in my possession from the start of updates through now), then in dom0 reinstall the old xen kernel such that both are present on the /boot filesystem? Trying that, hmm, I do not see the ability to install the old xen kernel side-by-side with the new one. When I try dnf install xen-hypervisor-4.19.4-1 for example it cannot find a match. When I try dnf search xen-hypervisor –showduplicates, it only finds the one, xen-hypervisor-2001:4.19.5-1.fc41.x86_64.

6

Suppose I do unsafe boot, then copy /boot/xen-4.19.5.gz (and .config) to /boot/xen-4.19.4.gz just so that the files exist for heads to continue. I don’t expect to be able to boot into that 4.19.4 (though maybe it would work and itdoesn’t seem particularly unsafe given that I’ll be booting into 4.19.5) but perhaps the presence of the file would help. Or better, simply touch /boot/xen-4.19.4.gz and .config.

If the issue is only the kexec_default_hashes.txt having the .gz file mentioned, then all I need to touch is /boot/xen-4.19.4.gz. Tried that first.

Now I get 31 files mismatching instead of 30, good, expected.

And voila. Signing the files works.

It appears that to avoid this issue in the future, I should set the default boot option to “Qubes (R4.3), with Xen hypervisor” because every other option names “Xen 4.19.5” which will disappear on the next Xen update, requiring hacking together this fix. I will try it, but sometimes I like to maintain some consistency and predictability in my boots. No, even setting this seemingly-generic-xen-version as default boot won’t prevent it because I see ./xen-4.19.5.gz in kexec_default_hashes.txt.

So this is a “solution” but not really. A better solution would be for the Qubes repo to keep several versions of Xen and/or heads to handle this situation more gracefully.

7

It looks like a solution in heads is in https://github.com/linuxboot/heads/pull/2150. Thanks to sergiid in dasharo support chat.