4 ms·
I've seen old tutorial from the Windows 7 era, tried to do the same with Windows 11 but failed. Can you explain how to use Windows bootmgr to chainload a linux
by csdvrx 3y ago
I've seen old tutorial from the Windows 7 era, tried to do the same with Windows 11 but failed.
Can you explain how to use Windows bootmgr to chainload a linux kernel store either in the EFI or the NTFS?
The goal is to use the same menu that shows different Windows versions from different drives
- Dalewyn 3y agoThe TL;DR is you dump a bootloader (eg: the 446 bytes of GRUB that would reside in a Master Boot Record) into a Windows-accessible file and then add a selection to Windows Boot Manager (or NTLDR) that points to that file. It will then happily execute whatever is there, such as GRUB or the Windows 9x bootloader, and hand over control. Yes, this means if GRUB subsequently has its own selection for Windows Boot Manager you can go and dance between the two forever. :P Seeing as the system is booting into Windows Boot Manager first, I think it should satisfy any SecureBoot demands if you want to actually boot GRUB or something afterwards.
- fuzzfactor 3y agoThis works on BIOS PC's or many times on UEFI machines which Have CSM enabled. But still have not found a way to boot Linux from Windows boot loader in plain UEFI. Where those exact 446 bytes are completely ignored. OTOH, booting Windows from a linux UEFI bootloader is still fundamentally as easy as it was a few years ago once the Linux community had legitimately acquired microsoft-signed bootloader shims. Except since then these specific Microsoft-signed keys "became" compromised, and are presently in the process of being blacklisted[0]. "Early-adopters" were expected to manually update their motherboards along the lines published here: https://support.microsoft.com/en-us/topic/kb5025885-how-to-manage-the-windows-boot-manager-revocations-for-secure-boot-changes-associated-with-cve-2023-24932-41a975df-beb2-40c1-99a3-b3ff139f832d https://support.microsoft.com/en-us/topic/kb5025885-how-to-m... Take a close look at the FAQ and Troubleshooting sections at the bottom of this article. And these are focused on potential problems with Windows itself. For Linux you need to interpret this information yourself. Which is also the article where the expected deployment staging schedule shows that the blacklisting process will eventually be complete no sooner than October 8, 2024. As time draws near, anyone who has not manually taken action will have their original keys be corrected in stages by being silently autoreplaced by spares. This autoreplacement seems to be occurring recently while running updated Windows 10 & 11 installs. Looks like a new executable, SecureBootEncodeUEFI.exe, was downloaded during an update, and has been reaching the designated spawning date for many users: https://learn.microsoft.com/en-us/answers/questions/1286247/securebootencodeuefi-exe-keeps-opening-a-shell-win https://learn.microsoft.com/en-us/answers/questions/1286247/... https://answers.microsoft.com/en-us/windows/forum/all/securebootencodeuefiexe/fe0aa6b3-e31f-4040-9aee-9e5999d834bf?page=1 https://answers.microsoft.com/en-us/windows/forum/all/secure... I saw the CMD popup while I was running an updated W10 on an especially slow PC. According to the calendar, this is a really drawn-out process, and until it's over[1] we will remain in a transition period where you never know which keys you need to have on your media in order for it to boot on any one particular motherboard. . [0] https://arstechnica.com/information-technology/2023/05/microsoft-patches-secure-boot-flaw-but-wont-enable-fix-by-default-until-early-2024/ https://arstechnica.com/information-technology/2023/05/micro... >Fix will eventually render all kinds of older Windows boot media unbootable. Not only "old" Windows boot media, Linux boot media is a target that can not be considered merely "collateral damage". [1] It will only be completely over once all UEFI PC motherboards in existence have been updated to perfection. Well, really after that only once all UEFI-bootable media has been corrected to match perfectly as well. Haven't seen any articles on how this is supposed to be accomplished though . . . Could very well be some subtle encouragement to discard all old media for some reason.
- csdvrx 3y ago> But still have not found a way to boot Linux from Windows boot loader in plain UEFI. Where those exact 446 bytes are completely ignored. That's exactly what I'm looking for: chainloading from bootmgfw by adding entries with bcdedit: this is because winload.exe loads the kernel (ntoskrnl) by reading the BCD, so maybe it's possible to make it load a linux kernel, or to replace winload.exe by something that will (you can revert that with `bcdedit /set {default} path \windows\system32\boot\winload.exe`) Have you explored that?