acl-grub: use dedicated /usr verity hash partitions consistent with UKI; fix arm64 test-image device-init timeout#36
Merged
Conversation
added 2 commits
July 23, 2026 20:23
GRUB's disk_layout.json previously used the legacy single-partition inline-hash verity scheme. The UKI-side changes in this branch switched grub.cfg's verity cmdline construction to UUID=-based hash identification (dropping hash-offset=), which only works when the hash tree lives on its own independently-discoverable partition. Mirror disk_layout_uki.json's structure: add dedicated HASH-A/HASH-B partitions (dps-usr-verity type) cross-referenced via verity_hash, so blkid/udev can resolve systemd.verity_usr_hash=UUID=<verity_uuid> the same way UKI does. ACL-GRUB still cannot do Trident A/B updates (no addon-swap equivalent), but the partitioning/verity mechanics are now consistent between the two boot paths instead of silently broken on GRUB. ESP stays at 128MiB (no AB-staging need on GRUB). BIOS-BOOT partition is kept (shared with Portage/flatcar builds; RPM/GRUB mode already skips installing to it).
install_uki_timeout_addon already works around a CI-only QEMU-TCG flake on arm64 kola test images: heavy parallel-VM CPU contention can prevent udev from initialising ESP/OEM/usr-verity devices within the default initrd device timeout, dropping the VM to an emergency shell. That fix was UKI-only (built as a signed .efi addon dropped into <uki>.efi.extra.d/). GRUB has no addon mechanism, so add install_grub_timeout_override: since grub.cfg is plain text (not signed/embedded like a UKI), patch the already-written grub.cfg copies on the test image's ESP directly via sed, appending systemd.default_device_timeout_sec=120 to the shared linux_cmdline. Same scoping as the UKI addon: arm64 test image only (INJECT_DOCKER_SYSEXT=true), never applied to production images or amd64.
bfjelds
changed the title
bfjelds
marked this pull request as ready for review
July 24, 2026 17:28
bfjelds
merged commit Jul 24, 2026
80b37d3
into
user/bfjelds/ab-verity-partuuid-uki-addons-20260708
2 checks passed
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.
Follow-up to #28. GRUB's disk_layout.json still used the legacy single-partition inline-hash verity scheme, but this branch's grub.cfg/grub_install.sh changes switched the verity cmdline to UUID=-based hash identification (dropping hash-offset=), which requires the hash tree to live on its own independently-discoverable partition.
Confirmed via a live acldevel GRUB build: the image built, but hung at boot waiting on
dev-disk-by-uuid-<verity_uuid>.device(45s timeout, never resolves) since that UUID isn't blkid-discoverable when the hash is inline.Separately, real-hardware arm64 test runs surfaced a pre-existing GRUB-only gap: under CI's higher kola
--parallel(QEMU-TCG, no HW acceleration), udev can't always bring up ESP/OEM/usr-verity block devices within systemd's default ~45s device-init timeout, causing verity activation to fail and the image to drop to an emergency shell (acl.kdump/acl.kdump.grubflaked this way in CI). UKI test images already work around this viainstall_uki_timeout_addon(); GRUB test images had no equivalent since GRUB has no addon mechanism.Changes
build_library/disk_layout.json: add dedicated HASH-A/HASH-B partitions (dps-usr-veritytype) cross-referenced viaverity_hash, mirroringdisk_layout_uki.json. ESP stays 128MiB (no AB-staging need on GRUB). BIOS-BOOT partition kept (shared with Portage/flatcar; RPM/GRUB mode already skips installing to it).build_library/vm_image_util.sh: addinstall_grub_timeout_override()(arm64 test-images only, mirrorsinstall_uki_timeout_addon()'s scoping) which patchessystemd.default_device_timeout_sec=120directly intogrub.cfg'slinux_cmdline, since GRUB has no signed-addon equivalent for kernel-cmdline injection. Wired into both call sites ininstall_oem_package().Both fixes verified locally on real KVM hardware (amd64) and on a real Azure VM (arm64, via QEMU-TCG) -- confirmed the timeout hang reproduces reliably at
--parallel=24against the unpatched image and is fixed by the override, with the kernel arg verified present in the boot console log.ACL-GRUB still can't do Trident A/B updates (no addon-swap equivalent) -- these changes only fix the partitioning/verity mechanics and arm64 test-image timeout flakiness so GRUB boots and tests correctly, consistent with the UKI scheme instead of silently broken.