Use systemd-boot instead of GRUB for UEFI - #135
Open
gmcquillan wants to merge 1 commit into
Open
Conversation
GRUB allocates the kernel and initramfs from a heap it claims once at startup, below 4GB. On AMD Strix Point laptops the firmware fragments that region enough that the 242MB archiso initramfs has no contiguous home, and grub_cmd_linux aborts with "out of memory" before the menu ever renders. The systemd-boot loader entries have been in configs/efiboot/ since before 5b9bf62 switched UEFI to GRUB; they were just no longer wired into bootmodes. Re-enabling uefi.systemd-boot also makes _make_efibootimg size the FAT ESP around the kernel and initramfs, which the 23MB GRUB-sized ESP could not hold. The kernel's EFI stub allocates through EFI boot services across the full memory map, so the sub-4GB constraint disappears. Refs #8629 Claude-Session: https://claude.ai/code/session_01V1nN7cVJRp3kF9vc9Fc7o9
Author
|
Confirming that this definitely fixed my problem and I was able to install Omarchy with no other issues! |
This was referenced Aug 30, 2026
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.
Fixes the GRUB
out of memoryboot failure reported in omacom/omarchy#8629, which makes the installer unbootable on AMD Zen 5 (Ryzen AI 9 HX 370 / Strix Point) laptops.The problem
On the shipped
omarchy-4.0.1.iso:EFI/BOOT/BOOTx64.EFIis a 7,712,768-byte GNU GRUB 2.14 standalone image, and the only x64 UEFI loader on the medium.initramfs-linux-t2.imgis 253,458,904 bytes (242 MB), while the ISO's ESP is only 23 MB — so the kernel and initramfs sit outside the ESP and must be pulled in by the loader.linux/initrdpath needs a single contiguous allocation below 4 GB. Strix Point firmware fragments that region enough that 242 MB has no home, andgrub_cmd_linuxaborts before the menu renders.The kernel does not have that constraint:
vmlinuz-linux-t2reports boot protocol 2.15, "64-bit EFI handoff entry point", "can be above 4G".Why this is a regression
ea707f6(2025-09-10) set the ISO up with systemd-boot.5b9bf620"Use grub" (2025-09-21) replaced those bootmodes withuefi-x64.grub.esp/.eltorito, and02a9d48(2025-09-28) renamed them to today'suefi.grub.The systemd-boot config was never removed, and is still maintained.
94494c8(#77, April 2026, "Disable xe Panel Replay on live boot for Panther Lake compatibility") editedconfigs/efiboot/loader/entries/01-archiso-x86_64-linux.conf— a file that has not reached a built ISO since September 2025. That fix has never shipped.This PR just re-wires the existing configuration back into the build.
What changes
One line in
configs/profiledef.sh. Two effects:BOOTx64.EFIbecomes systemd-boot, which chainloads via the kernel's EFI stub. The stub allocates through EFI boot services across the full memory map, so the contiguous sub-4GB heap requirement disappears._make_efibootimgsizes the FAT image fromefiboot_files; the systemd-boot path includesvmlinuz-*andinitramfs-*.imgin that list, the GRUB path does not. Kernel and initramfs end up inside the ESP.BIOS/syslinux booting is untouched. Secure Boot posture is unchanged — the GRUB images were built
--disable-shim-lock, so neither loader is shim-signed and Secure Boot must be off either way.Verification
Built from
quattrowith only this line changed (bin/omarchy-iso-make, exit 0; archiso v87). On the produced ISO:EFI/BOOT/BOOTx64.EFIsystemd-boot 261.2-1-archEFI/BOOT/BOOTIA32.EFIloader/loader.conf+ all 4entries/*.conf*grub*Booted in QEMU/OVMF (q35, KVM, 8 GB, headless): splash at ~6 s —
timeout 0, straight through, no menu — archiso autologin on the t2 kernel at ~12 s, installer at ~30 s, stable at 240 s. Then written to USB and the same structure re-verified on the physical stick (6,472,525,824 bytes, byte-exact to the ISO).Caveat, stated plainly: QEMU/OVMF does not reproduce Strix Point's fragmented low-memory map. The emulated boot proves the ISO boots correctly via systemd-boot; it is not by itself proof that the Framework 16 failure is fixed. The structural argument — GRUB entirely absent from the UEFI path, kernel EFI stub allocating across the full map — is the basis for expecting it to. I'll follow up on the issue once I've booted the stick on the affected hardware.
Note for reviewers
This has to be a replacement rather than an addition. Each bootmode function calls
_make_efibootimg, which recreates the ESP from that bootmode's ownefiboot_files, so listing bothuefi.grubanduefi.systemd-bootmeans the last one wins and the outcome depends on array order. Also noteuefi-x64.systemd-boot.esp/.eltorito(the pre-5b9bf620names) are deprecated stubs in archiso v87 whose bodies arereturn 1—uefi.systemd-bootis the working name.https://claude.ai/code/session_01V1nN7cVJRp3kF9vc9Fc7o9