On Saturday, 26 December 2020 06:28:44 GMT Walter Dnes wrote: > This is my first UEFI install, so please pardon the questions. > > 1) Partitioning questions: The standard layout example in > https://wiki.gentoo.org/wiki/Handbook:AMD64/Full/Installation#What_is_the_BI > OS_boot_partition.3F says... > > > The BIOS boot partition is needed when a GPT partition layout is used > > with GRUB2 in BIOS/Legacy mode. It is not required when booting in > > EFI/UEFI mode. > > The standard layout example is... > > Number Start End Size File system Name Flags > 1 1.00MiB 3.00MiB 2.00MiB grub bios_grub > 2 3.00MiB 131MiB 128MiB boot boot > 3 131MiB 643MiB 512MiB swap > 4 643MiB 20479MiB 19836MiB rootfs > > Given that my machine is incapable of booting in BIOS/Legacy mode, I > assume that the 2-megabyte partition is unnecessary, grub or no grub.
Your assumption is correct. This BIOS-GRUB partition is used on GPT partitioned drives to hold the GRUB 2nd Stage files. Since you're not familiar with GRUB it may help to add some background on the GRUB boot manager architecture. It contains two stages, some argue 3 stages if you include /boot/grub/. The Boot Loader code takes up 446 bytes and is stored in the MBR - sector 0 of the disk. This is the 1st Stage. The 2nd Stage contains files and drivers required by GRUB to be able to jump to and read the contents of any filesystems used on the OS /boot partition. On a disk with a conventional DOS partition table, the 2nd stage files would be normally stored in the "MBR gap", the empty space in the sectors following sector 0 and before the OS partitions start. This presents a problem on disks partitioned with a GPT, when installed on a legacy BIOS MoBo. This is because sector 1 of the GPT partitioned disk is used by the GPT partitioning structure to store the partition table. So, the solution for a GPT disk is to use a dedicated partition, the GRUB-BIOS partition, in which the 2nd Stage GRUB files can be stored. On a UEFI MoBo, the Boot Loader code is in the UEFI firmware itself, stored in the EEPROM. This code contains all requisite drivers to be able to scan the disk, identify the ESP partition and pick up any .efi executables in its VFAT filesystem. No other boot loader MBR code is required. 3rd party Boot Managers like GRUB will install their grubx64.efi image in the ESP and this in turn will load any necessary drivers and files to load the GRUB boot menu and any selected OS kernel image thereafter. > Also, given bloat over time, is 128 megabytes still sufficient for the > boot partition today? I plan to keep 2 kernels around at all times, > "Production" and "Experimental". I tend to keep 2 - 3 kernels at a time in the ESP. Along with their corresponding System.map and kernel config files also stored there, 2 kernels currently occupies 26MB. This is on a Gentoo system with no other OS present and no 3rd party boot managers. A laptop, which also has MSWindows OS on it, takes up 54MB of the ESP. I use the UEFI firmware to switch between kernels and live media at boot time. I manage the UEFI menu entries and their order using the efibootmgr application on a CLI, whenever I install a new kernel. If you switch between OSs and live media all the time, then GRUB, rEFInd, et al., would arguably be more convenient. I use 250-500MB for ESP partitions and for my needs this is way more than adequate. If you install 10s of multiple OSs, initramfs, and other applications, then you might need more space. HTH.
signature.asc
Description: This is a digitally signed message part.
