Re: [gentoo-user] UEFI data corruption? [FIXED]

[Mick]

On Thu, 26 Sep 2019 at 15:47, Peter Humphrey <peter@××××××××××××.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