Re: debian installation issue
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
Reply to: