Hello! I am a developer using my machine for programming, and I recently decided to dual-boot Windows 11 and CachyOS. I wanted a modern, fast setup, so after some digging I chose Limine alongside CachyOS's automated Snapper configuration. I am using Secure Boot with custom certificates signed via sbctl, and my LUKS keys are bound to my TPM.
While CachyOS boots flawlessly, I ran into a major roadblock with Windows: every time I boot Windows through Limine, BitLocker forces me into the recovery screen to enter my long recovery key.
I don't know a whole lot about the deep inner workings of bootloaders, but after a lot of troubleshooting and researching, I discovered why this happens. Limine's current protocol: efi reads the Windows boot manager into memory and handles the execution chain internally. Because of this, the TPM logs Limine's footprint and alters PCR 4 (the bootloader path). Windows sees this alteration, assumes the boot chain was tampered with, and locks me out.
I know Limine features the protocol: efi_boot_entry option, which uses BootNext to force a warm restart into Windows. While this successfully keeps the TPM path clean and stops BitLocker from tripping, it forces my motherboard to POST twice. This adds an extra 5 to 10 seconds to the boot time every time I want to switch to Windows to work or test code.
On the other hand, a bootloader like rEFInd avoids this by cleanly unloading itself and handing execution completely to the native UEFI image loader without forcing a hardware reset.
Proposed feature
To keep Limine's codebase clean and minimalist while giving dual-booters a smooth experience, I would love to propose adding a third EFI protocol option: protocol: efi_handover (or a similar flag/protocol implementation).
Instead of Limine parsing the target binary file and allocating memory itself, this protocol would defer directly to the motherboard's built-in UEFI image framework.
Conceptual Implementation:
When protocol: efi_handover is specified with a path, Limine would leverage standard UEFI firmware functions:
Translate the configuration text path into a native UEFI device path.
Call gBS->LoadImage() so the system firmware natively registers and caches the target binary (e.g., Windows Boot Manager).
Call gBS->StartImage() to cleanly terminate Limine's execution loop and hand off the boot phase.
Sorry if this does not make sense or goes against the philosophy, and as I have said, I don't know much about bootloaders, and I will admint, the architecture for this feature was suggested by AI, when I asked it how rEFInd doe s it, and it said that this change would be around 100 lines of code, so this would not break the minimalist and clean code phisolophy?
Anyway, happy to hear any thoughts on this and if this is even a good idea. I used refind earlier, but I don't like how the UI is a png, and integration with automatic kernel discovery and snapper is not so straighforward, so that is why I am suggesting this change.
Hello! I am a developer using my machine for programming, and I recently decided to dual-boot Windows 11 and CachyOS. I wanted a modern, fast setup, so after some digging I chose Limine alongside CachyOS's automated Snapper configuration. I am using Secure Boot with custom certificates signed via sbctl, and my LUKS keys are bound to my TPM.
While CachyOS boots flawlessly, I ran into a major roadblock with Windows: every time I boot Windows through Limine, BitLocker forces me into the recovery screen to enter my long recovery key.
I don't know a whole lot about the deep inner workings of bootloaders, but after a lot of troubleshooting and researching, I discovered why this happens. Limine's current protocol: efi reads the Windows boot manager into memory and handles the execution chain internally. Because of this, the TPM logs Limine's footprint and alters PCR 4 (the bootloader path). Windows sees this alteration, assumes the boot chain was tampered with, and locks me out.
I know Limine features the protocol:
efi_boot_entryoption, which usesBootNextto force a warm restart into Windows. While this successfully keeps the TPM path clean and stops BitLocker from tripping, it forces my motherboard to POST twice. This adds an extra 5 to 10 seconds to the boot time every time I want to switch to Windows to work or test code.On the other hand, a bootloader like rEFInd avoids this by cleanly unloading itself and handing execution completely to the native UEFI image loader without forcing a hardware reset.
Proposed feature
To keep Limine's codebase clean and minimalist while giving dual-booters a smooth experience, I would love to propose adding a third EFI protocol option: protocol:
efi_handover(or a similar flag/protocol implementation).Instead of Limine parsing the target binary file and allocating memory itself, this protocol would defer directly to the motherboard's built-in UEFI image framework.
Conceptual Implementation:
When protocol:
efi_handoveris specified with a path, Limine would leverage standard UEFI firmware functions:Translate the configuration text path into a native UEFI device path.
Call
gBS->LoadImage()so the system firmware natively registers and caches the target binary (e.g., Windows Boot Manager).Call
gBS->StartImage()to cleanly terminate Limine's execution loop and hand off the boot phase.Sorry if this does not make sense or goes against the philosophy, and as I have said, I don't know much about bootloaders, and I will admint, the architecture for this feature was suggested by AI, when I asked it how rEFInd doe s it, and it said that this change would be around 100 lines of code, so this would not break the minimalist and clean code phisolophy?
Anyway, happy to hear any thoughts on this and if this is even a good idea. I used refind earlier, but I don't like how the UI is a png, and integration with automatic kernel discovery and snapper is not so straighforward, so that is why I am suggesting this change.