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.