Mailing List Archive

Duel boot - How to verify boot loader updates?
Hi,
This is a bit of a conceptual question, simplified but based on a
machine I do own, from someone who knows very little about boot loader
implementations. (I.e. - me) Thanks in advance for any pointers you can
provide.

Assume a machine with two separate M.2 SSDs. The M.2 devices are
identical in size and from the same manufacturer. For the sake of
discussion they are partitioned identically and they both have the same
distro installed. One is stable, the other is bleeding edge. For simplicity
there are no other disk drives involved in either installation. Both
installs have the same boot loader, grub2 I guess, and both have
configurations that boot themselves by default but offer the other drive as
a second option.

Assume the bleeding edge system (or the other - it doesn't matter to me)
gets a grub2 update, and further assume the update is either automatic or
done by someone other than yourself. Whoever did the updates 'tests' the
machine by booting into both versions, and both versions are tested as
default in BIOS so that no matter what everything appears to be working.

THE QUESTION: After the fact, if I wanted to look at the two
installations in detail, how would I determine that the grub update was
done to the installation doing the update and not done to the other
(nearly) identical installation?

Thanks in advance,
Mark
Re: Duel boot - How to verify boot loader updates? [ In reply to ]
On Thursday, 8 December 2022 20:55:30 GMT Mark Knecht wrote:
> Hi,
> This is a bit of a conceptual question, simplified but based on a
> machine I do own, from someone who knows very little about boot loader
> implementations. (I.e. - me) Thanks in advance for any pointers you can
> provide.
>
> Assume a machine with two separate M.2 SSDs. The M.2 devices are
> identical in size and from the same manufacturer. For the sake of
> discussion they are partitioned identically and they both have the same
> distro installed. One is stable, the other is bleeding edge. For simplicity
> there are no other disk drives involved in either installation. Both
> installs have the same boot loader, grub2 I guess, and both have
> configurations that boot themselves by default but offer the other drive as
> a second option.
>
> Assume the bleeding edge system (or the other - it doesn't matter to me)
> gets a grub2 update, and further assume the update is either automatic or
> done by someone other than yourself. Whoever did the updates 'tests' the
> machine by booting into both versions, and both versions are tested as
> default in BIOS so that no matter what everything appears to be working.
>
> THE QUESTION: After the fact, if I wanted to look at the two
> installations in detail, how would I determine that the grub update was
> done to the installation doing the update and not done to the other
> (nearly) identical installation?
>
> Thanks in advance,
> Mark

Once booted into one of the OSs you could run something like 'eix -l grub' or
'emerge --search grub' to see which version has been installed. I don't
recall there being a GRUB filesystem specific pointer as to what version it is
when just looking at the installed GRUB files.

To check the GRUB version of the second OS without booting into it, you can
grep for grub in its /var/log/emerge.log
Re: Duel boot - How to verify boot loader updates? [ In reply to ]
On Fri, 9 Dec 2022 at 11:55, Michael <confabulate@kintzios.com> wrote:
> To check the GRUB version of the second OS without booting into it, you can
> grep for grub in its /var/log/emerge.log

Or see what version is named in the /usr/share/doc/grub-2.?? folder name.

On the other hand, if the question is *really* about knowing if
grub-install has been run on one of the machines, I don't know if
there is a way. Probably look at change dates on the files in
/boot/grub/?

Regards,
Arve
Re: Duel boot - How to verify boot loader updates? [ In reply to ]
On Fri, Dec 9, 2022 at 4:07 AM Arve Barsnes <arve.barsnes@gmail.com> wrote:
>
> On Fri, 9 Dec 2022 at 11:55, Michael <confabulate@kintzios.com> wrote:
> > To check the GRUB version of the second OS without booting into it, you
can
> > grep for grub in its /var/log/emerge.log
>
> Or see what version is named in the /usr/share/doc/grub-2.?? folder name.
>
> On the other hand, if the question is *really* about knowing if
> grub-install has been run on one of the machines, I don't know if
> there is a way. Probably look at change dates on the files in
> /boot/grub/?
>
> Regards,
> Arve

Thanks to both of you for your responses. I appreciate them, although I
don't think they get as far down in the weeds as I was wondering about.

My understanding of the boot loader - and maybe I'm using the wrong
terminology so if I am someone please correct me - is that at the start
of boot BIOS tells the processor to read some part of the disk and it is
the code read there that gets the whole process kicked off and
out of BIOS's control.

I'm wondering about that first bit of code being written by installation
#2's update into the initial section of installation #1's disk.

Rethink the picture a bit and make installation #1 Windows and
installation #2 Linux. Assume that after updating each install, and
further assume both installs made some very minor change to their
own first bits of code on the disk, and assume everything still
boots correctly, BUT assume that one of the updates actually
wrote into the other install's initial boot code and replaced it with
their own because it was confused about which disk it was
supposed to put this on. How would I be able to determine that
this happened?

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
Re: Duel boot - How to verify boot loader updates? [ In reply to ]
On Friday, 9 December 2022 17:17:24 GMT Mark Knecht wrote:
> On Fri, Dec 9, 2022 at 4:07 AM Arve Barsnes <arve.barsnes@gmail.com> wrote:
> > On Fri, 9 Dec 2022 at 11:55, Michael <confabulate@kintzios.com> wrote:
> > > To check the GRUB version of the second OS without booting into it, you
>
> can
>
> > > grep for grub in its /var/log/emerge.log
> >
> > Or see what version is named in the /usr/share/doc/grub-2.?? folder name.
> >
> > On the other hand, if the question is *really* about knowing if
> > grub-install has been run on one of the machines, I don't know if
> > there is a way. Probably look at change dates on the files in
> > /boot/grub/?
> >
> > Regards,
> > Arve
>
> Thanks to both of you for your responses. I appreciate them, although I
> don't think they get as far down in the weeds as I was wondering about.
>
> My understanding of the boot loader - and maybe I'm using the wrong
> terminology so if I am someone please correct me - is that at the start
> of boot BIOS tells the processor to read some part of the disk and it is
> the code read there that gets the whole process kicked off and
> out of BIOS's control.
>
> I'm wondering about that first bit of code being written by installation
> #2's update into the initial section of installation #1's disk.
>
> Rethink the picture a bit and make installation #1 Windows and
> installation #2 Linux. Assume that after updating each install, and
> further assume both installs made some very minor change to their
> own first bits of code on the disk, and assume everything still
> boots correctly, BUT assume that one of the updates actually
> wrote into the other install's initial boot code and replaced it with
> their own because it was confused about which disk it was
> supposed to put this on. How would I be able to determine that
> this happened?
>
> 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.
Re: Duel boot - How to verify boot loader updates? [ In reply to ]
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
Re: Duel boot - How to verify boot loader updates? [ In reply to ]
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.