Repository navigation
Keep the VM image bootable through the firmware after a kernel update - #293
Merged
Merged
Conversation
Install test passed
Boots are loader, kernel and userspace, without the VM's firmware. Install phases, x86_64
Install phases, aarch64
|
vm-seal empties /etc/machine-id, so each clone of the image takes its
own machine ID from the VM's SMBIOS UUID. /boot/limine.conf still names
the build's machine on its one entry ("comment: machine-id=<build ID>"),
and default_entry: 2 boots that entry's UKI. limine-entry-tool and
limine-snapper-sync look an entry up by machine ID first, and by name
only when the entry names no machine (TreeNode.findOsNode in both). So
on a clone:
- The first limine-mkinitcpio, which any kernel or mkinitcpio update
runs, adds a second "Omarchy" entry for the clone and leaves Limine's
default on the build's.
- Booted by vm-boot, which skips the firmware, there is no
/sys/firmware/efi, so the rebuild installs a plain kernel entry and
deletes omarchy_linux-omarchy.efi, the file the default entry boots.
The next firmware boot panics in Limine: "efi: Failed to open image
with path boot():/EFI/Linux/omarchy_linux-omarchy.efi".
- Booted through the firmware, the rebuild writes a new UKI to the same
path, and the default entry stops at "Blake2b hash ... does not
match! Press Y to continue" until someone presses a key.
- Before any rebuild, limine-snapper-sync exits 1: "Target OS name
'Omarchy' not found".
vm-seal now drops the build's machine ID from the entry, so every clone
finds it by TARGET_OS_NAME and updates it in place. Clones keep machine
IDs of their own.
vm-verify rebuilds the initramfs in its throwaway clone and checks that
the menu's entries stay as they were, that the entry Limine boots by
default changed, and that each file it loads is on the ESP with its
BLAKE2b. On the published 4.0.5 image (stable/4.0.5/450) four of the
six new checks fail and the other 20 checks pass; on the same disk
sealed with this change all 24 pass, in 14 s. Two clones of that
image, one rebuilt under vm-boot and one through the firmware, then
booted Limine's default entry to the desktop, with different machine
IDs.
emirb
force-pushed
the
vm-image/keep-limine-default-after-reseal
branch
from
October 19, 2026 21:56
104961c to
bcc3409
Compare
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
A clone of the nightly VM image stops booting through the firmware after its first initramfs rebuild, which any kernel or mkinitcpio update triggers. Limine's default entry then panics (
efi: Failed to open image with path boot():/EFI/Linux/omarchy_linux-omarchy.efi) or stops atBlake2b hash ... does not match! Press Y to continue. It reproduces on the published stable 4.0.5 image with no rc packages.vm-seal empties
/etc/machine-idso each clone gets its own machine ID, but it leaves the build's ID on Limine's boot entry (comment: machine-id=<build ID>), anddefault_entry: 2boots that entry. limine-entry-tool and limine-snapper-sync look an entry up by machine ID first, and by name only when it names no machine. So a clone's firstlimine-mkinitcpioadds a second "Omarchy" entry and leaves the default on the build's:Target OS name 'Omarchy' not found).vm-seal now drops the build's machine ID from the entry, so a clone finds it by
TARGET_OS_NAMEand updates it in place. Clones still get machine IDs of their own.vm-verify, which gates every nightly publish, now rebuilds the initramfs in its throwaway clone. It checks that the menu's entries stay as they were, that the entry Limine boots by default changed, and that every file it loads is on the ESP with its BLAKE2b. On the published 4.0.5 image four of these checks fail; on the same disk sealed with this change all 24 checks pass.
Installed systems keep their machine ID, so their entry is still found by it and this change doesn't affect them.