On Monday, 12 October 2020 10:15:16 BST pe...@prh.myzen.co.uk wrote: > On 2020-10-12 12:26 AM, "Jack" <ostrof...@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.
signature.asc
Description: This is a digitally signed message part.
