Re: debian installation issue
On Fri 11 Jun 2021 at 16:57:35 (-0400), Felix Miata wrote:
> Greg Wooledge composed on 2021-06-11 15:07 (UTC-0400):
> > On Fri, Jun 11, 2021 at 09:38:37PM +0300, Semih Ozlem wrote:
>
> >> How to check where grub is installed? And what is a friendly guide to
> >> learning about grub?
>
> > GRUB should be installed on the *disk* (not on a partition) that you
> > intend to boot.
> Not to detract from the wisdom of the rest of Greg's excellent reply, but TBC,
> this statement is religion at one extreme, opinion at the other, not fact. Note he
> wisely did not say "must", but "should". For most traditional (BIOS/MBR; designed
> for "Windows" PCs) configurations, it's probably prudent to put the bootloader on
> the "disk". For pure Debian installations, as opposed to multiboot, whether or not
> to install it on the "disk" really doesn't matter.
>
> 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.
Are there OSes that would install it themselves to a new blank disk?
> A less innocuous error is not clearly qualifying the quoted statement to apply
> only to non-UEFI boot environments, which usually means an MBR-partitioned boot
> disk. On a UEFI installation, which requires GPT partitioning, the first sector
> normally contains nothing until near its end, where a disk identifier and the
> start of the disk's multi-sector partition table begin. No executable code is
> required on this sector.
>
> 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.
# ls -GlgR /boot/efi/
/boot/efi/:
total 4
drwx------ 4 4096 Apr 3 2020 EFI
/boot/efi/EFI:
total 8
drwx------ 2 4096 Apr 3 2020 BOOT
drwx------ 2 4096 Apr 3 2020 debian
/boot/efi/EFI/BOOT:
total 3988
-rwx------ 1 1322936 Mar 2 16:23 BOOTX64.EFI
-rwx------ 1 1206824 Mar 2 16:23 fbx64.efi
-rwx------ 1 1549696 Mar 2 16:23 grubx64.efi
/boot/efi/EFI/debian:
total 5228
-rwx------ 1 108 Mar 2 16:23 BOOTX64.CSV
-rwx------ 1 1206824 Mar 2 16:23 fbx64.efi
-rwx------ 1 126 Mar 2 16:23 grub.cfg
-rwx------ 1 1549696 Mar 2 16:23 grubx64.efi
-rwx------ 1 1261192 Mar 2 16:23 mmx64.efi
-rwx------ 1 1322936 Mar 2 16:23 shimx64.efi
#
Whatever grubx64.efi is, it's copied from grub-efi-amd64-signed, aka
grub-efi-amd64-signed_1+2.02+dfsg1+20+deb10u4_amd64.deb currently.
> 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?
Cheers,
David.
Reply to: