Re: [gentoo-user] Re: [gentoo-user] UEFI booting again

[Michael]

On Monday, 12 October 2020 10:15:16 BST peter@××××××××××××.uk wrote:
> On 2020-10-12 12:26 AM, "Jack" <ostroffjh@×××××××××××××××××.net> wrote:
> > On 10/11/20 7:37 PM, Jude DaShiell wrote:
> > > If you followed the handbook /dev/sda2 would be where the boot record
> > > lives.>
> > I don't think so, but the terminology is certainly confusing. Peter
> > asked where efibootmgr writes something.  What is on /dev/sda2 could be
> > grub.cfg if it were mounted at /boot, and the grub booting stub (I
> > forget the correct name, but grubx64.efi) might be on /dev/sda2 if it
> > were mounted at /boot/EFI.  However, efibootmgr doesn't mess with either
> > of those.  It deals with what is stored in the UEFI boot firmware.  That
> > entry, which is read by the UEFI at boot time, runs the entry in the EFI
> > disk partition (usually under /boot/EFI), which then runs the kernel
> > (and possibly initramfs) in /boot.  Unfortunately, "boot record" is
> > probably too general a term.
>
> Yes, I meant the equivalent of that in an MBR system. Where the bootable
> kernel image lives is another matter.

The MBR's architecture is a bit different to UEFI.  Legacy BIOS in CMOS has a 
jump command to the MBR 'boot sector', stored @sector 0, which in the first 
446 bytes contains a bootstrap code and thereafter a partition table.  The 
bootstrap code signature is checked by BIOS and loaded in RAM where it is 
executed as a boot loader.  The bootstrap code (a.k.a. boot.img) contains a 
pointer to either Stage 1.5 or Stage 2.  Stage 1.5 starts on Sector 1 and has 
any filesystem drivers needed to access and read Stage 2.  Some boot loaders 
jump into a partition and load hardcoded sectors into RAM, which then run in 
order to load the rest of the OS boot image and execute it.  These are Stage 1 
boot loaders.  Other boot loaders like GRUB, load Stage 1 drivers and use 
these to access the stage 2 files in /boot, present a boot menu and load an OS 
kernel image.

With UEFI a lot of the above is stored in the much larger compared to CMOS 
UEFI firmware NVRAM.  The UEFI has its own bootstrap code, plus a boot 
manager, boot menu table and requisite device drivers, to access the ESP, or 
other bootable devices.

UEFI can load and execute any compatible UEFI applications from ESP, including 
OS boot loaders.


> I haven't been using grub, just efibootmgr to declare the image to the UEFI
> BIOS, and bootctl from systemd-boot to show a list of boot options.
>
> I assume there's something like an EEPROM on the motherboard to contain
> pointers (what I called boot records) to the the bootable kernel images.
> That's what I was asking about. I'm pretty sure that that table doesn't
> live on the disk. (Followers of this tale may remember that I had a problem
> with the NVMe disk; it turned out to be faulty, and I've replaced it.
> Windows could still boot on another disk without any intervention by me.)
>
> Can someone confirm or refute those ideas?

The UEFI firmware contains a number of variables in key/value pairs, stored on 
NVRAM.  One of these is a table containing a Boot Menu within an editable area 
of the firmware, which can be manipulated with the EFI shell (efibootmgr) to 
set, rename, delete bootable .efi images.

Upon a reboot the UEFI boot manager will scan the ESP and other similar VFAT 
partitions and bootable devices (CD/USB) for executable UEFI applications, to 
re-list any .efi bootable images it finds in its GUI boot menu.  If the 
previously configured boot menu order is lost/corrupted, a rescanned ESP may 
not arrive at the same order of bootable images.

As I understand it the concern of the OP here is the EEPROM chip may have 
corrupted its editable content.  Different OEMs have different solutions, with 
OOB hypervisors managing backup/restore functions, to using a secondary Boot 
Block found in the main Firmware chip, but at an alternate address location, 
to using two separate EEPROM chips and so on and using some jumper to restore 
from the backup.  If major firmware malfunction is suspected, then re-flashing 
the MoBo with the latest version of OEM firmware should hopefully restore 
sanity.  If the MoBo chip is faulty, or on its way out, then the failure mode 
will soon repeat itself.