Sorry, this is not a detail instruction a reasonable person would find adequate for a novice using Windows PC. No examples either. By now 12 pages of this topic - and no-one is able to present a clear instruction for a novice, how to add this thing to a Windows PC? Does it require a dedicated FAT32 or EFI partition, located at the internal HDD start? What are the exact Grub4DOS commands, etc.
Before discussing VHD boot issues with grub4efi, would it be reasonable to at least explain how to add this to a PC in a concise step-by-step guide anyone can repeat? It will engage a lot more people to the discussion. This is what I consider a sacred duty of any OP presenting a new bootloader or program.
It is not intended for novice users. (...)
That's no place to stay. We have to put together the pieces for such a tutorial. And while Liuzhaoyzz's tutorial (post 220) is brilliant, with its focus on RAM OS booting it starts well beyond the novize's position, which in my case could be characterized like this:
(...) I'm thinking about switching all my UEFI-supporting OSes to UEFI/GPT, while relegating older legacy OSes to VMs. I can still do legacy boot with all of them, but there's not much sense in trying to live in the past forever, since most future hardware won't support legacy at all.
So let's say I've got this spare shitty old laptop securely booting to Windows 10 and even 11 on a GPT disk. But as Liuzhaoyzz mentions ...
The essence of "secure boot" is that Microsoft suppresses Linux and charges protection fees in order to strengthen its monopoly. Dirty means, grub4dos/grub2 does not pay Microsoft a protection fee, so it cannot be directly started via secure boot. Generally, it is recommended to disable secure boot in the BIOS settings.
Then we would lag behind the development. Grub4DOS for UEFI must be bootable even on a "secure" PC. The Debian Wiki Team contradicts:
Other Linux distros (Red Hat, Fedora, SUSE, Ubuntu, etc.) have had Secure Boot working for a while, but Debian was slow in getting this working. This meant that on many new computer systems, users had to first disable SB to be able to install and use Debian. The methods for doing this vary massively from one system to another, making this potentially quite difficult for users. Starting with Debian version 10 ("Buster"), Debian included working UEFI Secure Boot to make things easier. (...)
UEFI Secure Boot is not an attempt by Microsoft to lock Linux out of the PC market here; SB is a security measure to protect against malware during early system boot. Microsoft act as a Certification Authority (CA) for SB, and they will sign programs on behalf of other trusted organisations so that their programs will also run. There are certain identification requirements that organisations have to meet here, and code has to be audited for safety. But these are not too difficult to achieve. SB is also not meant to lock users out of controlling their own systems. (...)
Shim is a simple software package that is designed to work as a first-stage bootloader on UEFI systems.It was developed by a group of Linux developers from various distros, working together to make SB work using Free Software. It is a common piece of code that is safe, well-understood and audited so that it can be trusted and signed using platform keys. This means that Microsoft (or other potential firmware CA providers) only have to worry about signing shim, and not all of the other programs that distro vendors might want to support.
Shim then becomes the root of trust for all the other distro-provided UEFI programs. It embeds a further distro-specific CA key that is itself used for signing further programs (e.g. Linux, GRUB, fwupdate). This allows for a clean delegation of trust - the distros are then responsible for signing the rest of their packages. Shim itself should ideally not need to be updated very often, reducing the workload on the central auditing and CA teams.
On each architecture, Debian includes various packages containing signed binaries: (...) grub-efi-amd64-signed (...)
So I would expect my test computer to be securely dual-bootable to Windows 10/11 and Debian 10, with the latter's signed Grub2 for UEFI to be able to chainload our new Grub4DOS for UEFI, such that I could do my unsecure booting experiments with virtual disks, right? Which would be the menu entry for Grub2?
(Just that my preferred Linux is openSUSE Tumbleweed, which is very much like Windows because as a rolling release it must not be re-installed for years, at least in theory. openSUSE also focuses on hypervisors and has a Yast GUI to configure the Grub2 boot manager.)