Hacker News Reader

>the Windows Boot Loader,

Just FYI, Windows Boot Manager (and also its predecessor NTLDR) can chainload into any other bootloader including GRUB. Originally intended to support dualbooting Windows NT with Windows 9x, it's actually quite handy and reliable.

>I flatly refuse to purchase a mass-market computer ever again.

There's your problem. "Big box" store-bought computers have motherboards that are locked down and devoid of most advanced features.

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

The 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.

This 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-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/...

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/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.

> 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?

That's surprising. I never experienced that. All I do is format USB stick with FAT32, copy files from ISO and it just works.

I invite you to give that a shot on either an LG 16Z90R or a Dell Inspiron 7710.

while I don't have any of those machines readily available, i am curious if this USB image [1] would work. It's a lightly customized Alpine which can be written to a flashdrive using either Rufus, usbimager, or this command: xz -dkc <asm.usb.xz >/dev/sdi

the image was built using this repo [2] and this command: ./build.sh -i dl/alpine-standard-3.19.0-x86_64.iso -p min -s 0.3

[1] https://ocv.me/asm.usb.xz [2] https://github.com/9001/asm

Would've been happy to try this, but this device has already been shipped to the recipient. FWIW the consensus was that Secure Boot on the Inspiron was still partially active, even after disabling it in BIOS. If this image is capable of running with Secure Boot enabled, then it should work. If it requires disabling Secure Boot, then it probably wouldn't.

In that case we probably have the answer already :) The next question then would have been whether secureboot-signing it yourself and replacing the PK/DB in the BIOS would have made it work, but it's really unfortunate that we've gotten to this point.

Yeah. I was genuinely surprised at how hostile the process has become. These were the most difficult installs I've ever had by far, and for entirely different reasons than in the past. Contrary to past installs, once I finally got the OS on there, everything else worked better than expected.

Here we go again: Leave that damn windows bootloader alone. Create new partition for the new bootloader, set it as default boot partition. When booting choose "Windows boot mgr" in GRUB (may need to run osprober), it'll work fine. This way windows can keep it's bootloader healthy, and you can boot to both OSes.

Appreciate the advice, but I have no interest in booting Windows and would rather not keep its boot loader. On the exceedingly rare occasion that I need Windows for something, a VM is far more convenient than a reboot.

Hm, I'm confused- why you do not just wipe the Windows install entirely then?

I do, but that requires either successfully booting something else or pulling the drive. Manufacturers are making it incrementally harder to successfully boot something else. Pulling the drive is still an option, but it turned out that I didn't have the right NVME adapter and one wasn't available locally, and in any case, if you do that and still can't get it to boot, then you have to have a backup image of the drive or you're really SOL. If the device still boots Windows in any condition, I can still return it to the retailer as a plan Z.

I'm afraid I'm totally lost. Do you not just plug in a USB drive with a Linux ISO, hit the key combo for the boot menu, and boot off the USB? Maybe you need to disable secure boot in the BIOS/UEFI, but that's about it, no?