David Wright composed on 2021-06-22 10:50 (UTC-0500): > On Fri 11 Jun 2021 at 16:57:35 (-0400), Felix Miata wrote:
>> OTOH, putting a bootloader on the MBR of a disk on a PC designed for Windows >> is a >> relative newcomer to the world of booting such a PC. I've been installing >> operating systems on IBM-compatible PCs for more than 3 decades. Not once >> have I >> intentionally installed Grub on an MBR. In the dearth of instances where it >> did >> happen I wiped whatever caused it, and started over with >> DOS/OS2/Windows/Linux-compatible MBR code on the MBR. IOW, Grub can live >> elsewhere >> than on the MBR. > Can you elaborate on what your "DOS/OS2/Windows/Linux-compatible MBR > code" is, what functionality you get, and where you obtain it. I'm not sure there is "a" definition. One could be any code that a Windows installation would not replace. Another could be based on what it does: 1-locate a legal boot flag 2-load an appropriate sector pointed to by a legal flag 3-announce error if the above conditions are not met A legal flag is any flag on a primary partition on a disk on which no other boot flags are present in the MBR table. > Are there OSes that would install it themselves to a new blank disk? One version would be code a Windows installation would put there. Another would be the result of FDISK /MBR from a MS or PC DOS boot, or FDISK /NEWMBR or LVM /NEWMBR from an OS/2, eCS or ArcaOS boot. I would expect the FreeDOS version of FDISK or its installer to do the same. I normally use code derived from OS/2, installed by DFSee when I first partition a disk. >> With a UEFI "BIOS", the boot process begins rather differently than on an >> MBR-only >> system. On a UEFI system's ESP (Extensible Firmware Interface System >> Partition; a >> quasi-"boot" partition), there are no files containing the string "grub" in >> their >> name. I have no idea what I was thinking when I wrote that last sentence. I was probably looking at an installation that had been installed without any bootloader, which is not where I should have been focused. >> Thus it seems to be a debatable issue whether "bootloader" is actually an >> appropriate name for Grub 2, as its primary purpose seems to be presenting a >> menu >> from which to select what kernel, initrd (if any), and kernel command line >> parameters (if any) to load into RAM to /continue/ the boot process >> initiated by >> the UEFI firmware. > I'm not quite following your point. Are you saying that the ~250 Grub > modules are just a waste of space, and that the while boot process is > carried out by the EFI firmware? The process is initiated by the EFI firmware, begun by probing a panoply of available media for ESP partition files that fulfill requirements for proceeding with a boot process defined by the Multiboot Specification. Usually, it's more or less the start of a chain loading process finished by an installed "bootloader". OTOH, the UEFI firmware might start a PC completely (of sorts) by loading a single file on the ESP originally named mt83x64.efi (memtest86 v8.3). All the Grub modules aren't required or employed on any given installation. A more sophisticated Grub installer could conceivably install there only those components required for the hardware present during installation. -- Evolution as taught in public schools is, like religion, based on faith, not based on science. Team OS/2 ** Reg. Linux User #211409 ** a11y rocks! Felix Miata