initrd/bin/kexec-sign-config.sh: stop re-hashing stale default entry paths on -u update

[tlaurion]

Remove the -u block that re-hashed file paths extracted from the old kexec_default_hashes.txt. Those paths are from a previously saved default boot entry. If a distro replaced a versioned boot file in-place (e.g. Qubes OS bumping xen-4.19.4.gz to xen-4.19.5.gz), the old path no longer exists on disk and sha256sum fails, aborting the entire update with DIE.
Read: delete old binaries at the same time of providing new ones, which never happened before.

Qubes OS does NOT fan out old and new xen binaries on /boot: a dom0 update replaces xen-4.19.4.gz with xen-4.19.5.gz in-place (QubesOS/qubes-vmm-xen#220, shipped to stable via QubesOS/updates-status#6746 on 2026-07-02). Other distros (Fedora, Arch, Debian, NixOS, Ubuntu...) keep old kernels+initramfs alongside new ones, so the old paths still resolve and the re-hash failure was never observed there.

The re-hash had been present since its introduction in 2018 but went unnoticed because most distros keep old kernel/xen files on disk alongside new ones, so the old paths still resolved.

The failure is now fatal because the -u (update) and -r (rollback counter) flags are passed together in a single call. When the re-hash fails, DIE is called before the rollback counter is ever incremented, leaving the system with a partially updated kexec_hashes.txt but no counter bump. This coupling was introduced in commit 8bfae52 (Oct 2020), which restructured update_checksums to always call kexec-sign-config with -u hardcoded and -r as extparam.

Regression lineage:

• Mar 14, 2018 - @kylerankin introduced the re-hash in update_checksums() inside gui-init (commit 769f6a7).
• Jul 5, 2019 - @MrChromebox moved update_checksums() to /etc/functions (commit ed2f19d).
• Oct 8, 2020 - @alex-nitrokey moved the re-hash block into kexec-sign-config under the -u flag and coupled it with -r (rollback) in the same call (commit 8bfae52).
• Through 2026 - No OS removed boot binaries atomically without leaving old files in place, so the coupled failure went untriggered.

Mitigation on unpatched firmware (recovery shell):

mount -o rw,remount /boot
rm /boot/kexec_default_hashes.txt
mount -o ro,remount /boot
reboot.sh

Then re-run Update checksums. The -e guard skips the re-hash when the file is gone. Then set a new default from the boot menu.

Fix: skip the re-hash entirely. The user re-saves the default boot entry from the boot menu to regenerate kexec_default_hashes.txt.

---

Was discussed over matrix's Dasharo Premier support channel (subscribers only) here.

Affects all Heads + QubesOS 4.3 users

[Copilot]

Copilot wasn't able to review any files in this pull request.

---

💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.

[tlaurion]

QubesOS automated testing was testing (results still available as writing)

• T430 with Nitrokey's variant (unknown commit)
• V560TU 0.9.0 not 0.9.1 released https://docs.dasharo.com/variants/novacustom_v560tu/releases_heads/#v091-2026-05-11

Note that replacing xen-4.19.4.gz with xen-4.19.5.gz landed July 2nd, as per normal testing->release falling through all current automated testing in place for QubesOS QA/Dasharo.

CC: @marmarek @macpijan @pietrushnic, let me know how we want to handle this forward.

• One possibility is for QubesOS to drive emergency Xen binary update, not removing old one so grub.cfg entries are regenerated leaving user the possibility to revert older binary from availabe boot entries (as for current kernel/initramfs)
• Release a bugfix release for all platforms using Qubes (Novacustom/Nitrokey/Purism/HardenedVault/Others/All)
• Push mitigation as detailed in OP. No impact known for any other OSes since 2018; typically OS updates installs new kernel/initramfs do not force deletion of old ones "atomically": this is left for a cleanup process which respects the number of rollback of boot entries defined.

[Copilot]

Copilot wasn't able to review any files in this pull request.