On Thu, 26 Sep 2019 at 15:47, Peter Humphrey <pe...@prh.myzen.co.uk> wrote: > > On Thursday, 26 September 2019 10:16:54 BST Adam Carter wrote: > > > > The Gentoo Handbook says to create a small unformatted partition at the > > > > beginning of the (primary?) disk, then to create a FAT-32 partition for > > > > /boot, then whatever other partitions are required.
Strictly speaking the FAT32 partition is the ESP, which is typically mounted under /boot and it should be marked with the corresponding ESP GUID. As I mentioned before, the initial disk space (rather than partition) starting at LBA0 contains either a legacy MBR with its time honoured 4 partition table, or a Protective MBR containing a fake single whole-disk partition in its table. Either the legacy MBR or Protective MBR blocks are not processed by the UEFI firmware, which goes to LBA1 and reads the GPT tables to find the ESP. Therefore, it is not clear to me why a small empty partition might be necessary at the start of the disk, unless earlier versions of partitioning tools were not as clever and started at LBA0, or some some weird UEFI firmware implementations were devised by some OEMs. > > > Another question answered: yes, it has to be the primary disk. I installed > > > a small test system on another disk. It has its own FAT-32 /boot > > > partition, in which I set up a similar directory structure to the main > > > system's. Efibootmgr still insisted on adding the UEFI entry to the main > > > set, in spite of my telling it to use the secondary disk. And the BIOS > > > couldn't see the image on the secondary disk. I believe you'll need a bootloader to jump to different disks. I don't think the UEFI firmware in its current version can handle more than one ESP in any number of drives. Some OS auto-scripted installation media will fail if the same disk has two FAT32 partitions marked as ESP (e.g. Windows 7). > > I found my BIOS didn't recognise the UEFI setup until it was > > specified/setup by efibootmgr, so that checks out. What was the efibootmgr > > command you were using for the second disk? > > efibootmgr -c -p 3 -d /dev/sda -L "TestSys" -l '\EFI\BOOT\bootX64.efi' Did you try specifying the disk device before the partition? efibootmgr -c -d /dev/sdXX -p 3 ..... to see if it is recognised then? > > > The conclusion is that, at least on this motherboard, there is precisely > > > one set of UEFI boot images, and it lives on the primary disk of the > > > system. Well, I haven't yet worked out how much of it is on the disk and > > > how much in BIOS storage. The point remains, however, that I can't spread > > > boot images over several disks. > > > > That's pretty poor. > > It isn't what I expected either. The UEFI firmware implementation (should) follow its specification, which has evolved over time. The specification mentions OS boot loaders, or kernels, or EFI applications, should be stored within EFI/ subdirectories, one per vendor. The EFI/ directory itself must be at the root of the ESP filesystem. Each OS subdirectory must contain only one bootable image, or the boot behaviour for the system won't be deterministic. [1] There may be an EFI/BOOT/ subdirectory in which a recovery bootable image can be stored. This will be used if other OS' images fail to boot. With removable media the directory structure is slightly different. All bootable images (one per supported arch) should be stored under EFI/BOOT/. This will ensure the removable device will boot automatically. Additional UEFI executables must be in directories other than BOOT/. The moment you start deviating from the above you need to manually edit the boot menu with e.g. efibootmgr. It used to be the case only the primary disk was used/usable by the UEFI firmware and only one ESP. Later versions of the specification say they may cater for more flexible ESP arrangements in the future. The older the OEM UEFI implementation the less flexible it would be. > > What does efibootmgr show? > > # efibootmgr > BootCurrent: 0000 > Timeout: 1 seconds > BootOrder: 0000,0004,0005,0001,0002,0003,0006,0007,0008,0009,000A,000B > Boot0000* Gentoo Linux > Boot0001* UEFI:CD/DVD Drive > Boot0002* UEFI:Removable Device > Boot0003* UEFI:Network Device > Boot0004* CD/DVD Drive > Boot0005 Hard Drive > Boot0006* UEFI:CD/DVD Drive > Boot0007* UEFI:Removable Device > Boot0008* UEFI:Network Device > Boot0009* UEFI:CD/DVD Drive > Boot000A* UEFI:Removable Device > Boot000B* UEFI:Network Device > > I'll delete all those duplicates. I don't know what's creating them. It's > happened a few times since this mess started, but I never saw it once before > then. The UEFI firmware can also use the Simple File System Protocol, if the disk supports it. In this case, it will scan the GPT, jump to the root of a partition and read bootable files on it. Then it will populate its boot menu with them. Presently this will only work with FAT(12/16/32) fs formats. Some of the duplicates may have been created in this fashion. > > I got the impression that I would be able to UEFI boot from multiple > > different devices, eg a USB drive with UEFI as well as the hard disk. I may be wrong, but I don't think this is possible (yet?). You could use a secondary bootloader, e.g. GRUB, other than the UEFI firmware to load OS kernels wherever they might be positioned on the system. > Oh yes, removable devices can be booted, but not secondary, internal hard > drives. Apparently. On this system. Today. > > -- > Regards, > Peter. [1] https://uefi.org/specifications -- Regards, Mick
