Mailing List Archive

On Monday, 12 October 2020 10:15:16 BST peter@prh.myzen.co.uk wrote:
> On 2020-10-12 12:26 AM, "Jack" <ostroffjh@users.sourceforge.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.

On Monday, 12 October 2020 17:43:04 BST Michael wrote:

> 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.

[...etc]

Thanks Michael; more-or-less what I thought.

--
Regards,
Peter.