On Monday, 16 September 2019 08:50:37 BST Peter Humphrey wrote: > On Monday, 16 September 2019 08:41:34 BST Neil Bothwick wrote: > > On Sun, 15 Sep 2019 23:26:47 +0100, Peter Humphrey wrote: > > > Now you see, there seem to be two ways to arrange the esp and boot > > > partitions. The gentoo wiki says to leave a small unpartitioned space > > > for esp data, then create a vfat partition for /boot. That's what I > > > did. Other people seem to have both functions served by the /boot > > > partition. I think I tried that once but got snarled up somewhere.
The "small unpartitioned space" starts at LBA 0 of the disk and is used to store an MBR table, which lists a single large partition for the whole disk starting at LBA 1. By "large" I mean as large as an MBR can recognise, which is up to 2TB. This "small unpartitioned space" is called and functions as a 'GPT Protective MBR'. Its purpose is to stop legacy disk partitioning tools, which have no concept of GPT partitioning schemes, from over-writing unknowingly the GPT partitioning tables and data. Without this GPT Protective MBR, old disk partitioning tools would see an empty disk and proceed to partition it without warning. With the GPT Protective MBR they will at least seek confirmation to delete one large partition of unknown type. Unlike a 'GPT Protective MBR' which is not a partition, in the sense of not being specified anywhere in a partition table, the 'EFI System Partition' (ESP) is a ... partition. :-) It is specified along with other GPT partitions with a start and an end within the GUID Partition Table (GPT) of the disk. So, the two items "small unpartitioned space" and ESP are not the same. I'm not sure if they could be combined, but if they were, the GPT table which starts at LBA 1 will be referring to an ESP (partition) which is found somewhere within LBA 0, after the MBR table stored in there. This sounds messy to me, from a logical perspective at least. > > I was under the impression that the ESP had to be a FAT partition. The > > small unpartitioned space is for when you are using a GPT > > partition table with a non-EFI bootloader. Well, it's really unformatted, > > it is a partition. > > Ah. I didn't appreciate that. Looks like I misinterpreted the wiki page (and > I used to be able to read quite well, too.) Neil is partly right, the EFI System Partition (ESP) is a partition typically formatted with a FAT32 filesystem, where all the OS kernels and optionally boot loader files/firmware/microcode/drivers can be stored. However, it is not a FAT32 partition *type*, or in GPT terminology a 'Microsoft Basic Data Partition', but an ESP partition type. Upon its creation the ESP is set as partition type 'esp' (parted), or 'EFI System' (fdisk), or 'ef00' (gptfdisk). The partition type label for ESP is C12A7328-F81F-11D2-BA4B-00A0C93EC93B. On Linux it is mounted under the /boot mountpoint. NOTE: On a disk which has been configured with a MBR partitioning scheme the ESP partition will be shown as partition type 'ef EFI (FAT-12/16/32)' > > That's how I do it on non-EFI systems, on UEFI machines, I always make > > /boot a FAT partition and use it as the ESP too. > > I'll try that. Thanks Neil. Hmm ... I think we're saying the same thing, but I may have lost the thread: On non-UEFI systems I use an MBR partition table, create a partition and set it as Linux type (82), format it with ext2 and mount it under the /boot mountpoint. Then drop my kernels in there and install the boot manager files (GRUB). On UEFI systems I create an ESP partition type, format it with a VFAT filesystem, then mount it under the /boot mountpoint. Then drop my kernels in there (I use the efi kernel stub to boot directly these kernels, rather than a boot manager like GRUB). Thinking about it, on legacy BIOS MoBos I've always used MBR partition tables, but I haven't installed one of those for some years now. All current versions of linux disk managers use 4k sectors and leave the first sector empty, where the GPT Protective MBR table will be stored. I think they will do the same, leave the first 4k sector empty, on a MBR partition scheme too and store the MBR partition table in there. The older disk management tools used 512 byte sectors and only the first 512 bytes was used for the MBR tables. So with a 4K sector most of it will be left empty. Anyway, I'm no authority on the above topics, just sharing my understanding. Please point out any errors as you find them. -- Regards, Mick
signature.asc
Description: This is a digitally signed message part.
