Re: [gentoo-user] Duel boot - How to verify boot loader updates?

[Michael <confabulate@kintzios.com>]

[-- Attachment #1: Type: text/plain, Size: 2999 bytes --]

On Friday, 9 December 2022 18:39:33 GMT Mark Knecht wrote:
> On Fri, Dec 9, 2022 at 10:57 AM Michael <confabulate@kintzios.com> wrote:
> > On Friday, 9 December 2022 17:17:24 GMT Mark Knecht wrote:
> <SNIP>
> 
> > > It's not totally a thought experiment. One machine I have which
> > > is dual boot recently complained that the original disk grub was
> > > installed on had changed when in fact there hadn't been any
> > > hardware changes and I had to carefully figure out how to
> > > answer a couple of questions. After the fact I started to wonder
> > > about this edge case.
> > > 
> > > I think it comes down to reading what's on the disk with a
> > > hex editor possibly but I know nothing about what to expect
> > > there.
> > > 
> > > Thanks,
> > > Mark
> > 
> > Before I venture a potentially wrong answer, could you please clarify if
> > we are talking about a UEFI MoBo, or a legacy BIOS MoBo.
> 
> The specific machine where this happened is UEFI.
> 
> Thanks

Without more information on the errors GRUB produced I can't comment on the 
specific experience you had, other than to say you can install GRUB on a 
different disk/partition than the one the OS is on.  Perhaps GRUB complained 
about being updated from a different OS used for its installation?

Anyway, let's briefly clarify the BIOS startup process you mentioned, if only 
to explain why I don't think this is related to the errors you mentioned.

On legacy boot systems the BIOS code is quite limited in what it can do.  It 
just jumps to the 1st disk, first sector (LBA 0) and runs what it finds there.  
This era of technology used the MBR disk partitioning scheme and the first 
sector contained the boot loader code as well as the disk partition table.

Modern UEFI systems use more capable EFI firmware (a.k.a. BIOS) and normally a 
GPT formatted disk.  This modern system does not require any boot loader code 
to be written in LBA 0.  The boot loader code is part of the UEFI firmware 
itself and is capable of loading and executing EFI compatible 'applications' 
stored in the FAT 32 formatted EFI/ partition (ESP) on the first disk.  GRUB's 
EFI executable 'grubx64.efi' stored in the ESP on the first disk is loaded and 
executed by the MoBo's UEFI firmware.

If I were to hazard a guess, the GRUB error messages you received are not 
related to the BIOS init sequence, but the GRUB configuration.  Probably some 
mismatch between the filesystem UUID, GRUB's root prefix and perhaps the 
PARTUUID between the current OS and the one used to clone/install GRUB in the 
OS at the beginning.  You could try to decipher this manually, by running 
blkid, to list your partitions and their respective UUID and PARTUUID.  Then 
editing grub.cfg and/or any files if necessary under /etc/default/

On the other hand, it would be easier to reinstall grub on the OS you are 
currently booted into, with 'grub-install' followed by 'grub-mkconfig' to 
update its grub.cfg file.  This should straighten out any discrepancies.

[-- Attachment #2: This is a digitally signed message part. --]
[-- Type: application/pgp-signature, Size: 833 bytes --]