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

<div dir="ltr">Hi,<div>   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.</div><

<br></div><div>   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.</div><div><br></div><div>   Assume the bleeding edge system (or the other - it doesn&#39;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 &#39;tests&#39; 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.</div><div><br></div><div>   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?</div><div><br></div><div>Thanks in advance,</div><div>Mark</div></


--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On Fri, 9 Dec 2022 at 11:55, Michael <[email protected]> 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

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

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
-----BEGIN PGP SIGNATURE-----

iQIzBAABCAAdFiEEXqhvaVh2ERicA8Ceseqq9sKVZxkFAmOTE+0ACgkQseqq9sKV ZxktMhAAyr+t/mvkQP9RXPVfGwJSmBYE5tmEq/TvUbC/79ERWU7sDv05gQEB1Pe4 Lc0/VK7pbNOXreOr/8dL7hACviIb/go+MCGAuSZWs2FzSnjuhC+tL6BS7OC89aRs jAQJVLWh5Zlm2sOtoGMXinyehBcN9T2z26bLizv1mGz0u/uOfNPDGnrDlA8UVIbe LIQyAgMrI1rVfTWwhCYbI8cB3n3MUAWSS1TlC/JmTGmkiCjcRBzMkI2sydhPmXN2 FwyDwbdLmka/Y9pwl0asfu2rYiTagu9DuMBCoHVXPFAvxdNDFdlOK+9xenM4230p LwyfAbokUimyMgzL61jnoU4lJTn5tcSbAG/Vt3iDzwzv/N+erqSpNAAJQDbAp3Kf YeKvcJheGsDFNQSvZGfu0wp/DWpd/gf7ihCC2euJnyKu8WsCun9/0rSIYD+AiiZS MitN6O4ICftu7t2ACfRxSAkROenZdu5eX7hEL1+uZxzxCSTqojRO4kvtz4rHLYYN uXgHNhatGT53iCNCg/Os136ebN8YTpyLYx63j/Qx1/tFtvPItxLhF0SWm96t+urt KFdJ9MV5lzsUdM/FFc5XqQ6r/SkJALjMkK3KwUKDhABUxZkNFTjGKvR+2AmklhMB suumuzRedlh2FMxuh6MIf8IrxUlQ+wHX3Q4iJpM5ej/w4aXSXCs=
=ge86
-----END PGP SIGNATURE-----

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On Friday, 9 December 2022 17:17:24 GMT Mark Knecht wrote:

On Fri, Dec 9, 2022 at 4:07 AM Arve Barsnes <[email protected]> wrote:

On Fri, 9 Dec 2022 at 11:55, Michael <[email protected]> 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.
-----BEGIN PGP SIGNATURE-----

iQIzBAABCAAdFiEEXqhvaVh2ERicA8Ceseqq9sKVZxkFAmOTdt0ACgkQseqq9sKV ZxlBSRAAi/xHLbbWErU5ASWsEFRMH9D3ieezJ4JoYcHb1iY3njte4m46/a9C22Fe 0MxW2/xF4SsZuKehQdI0SYz1s3MJEzAK0BCO73pHPGyjIXQDCo8LFn4z9WMRJD/T lh+1Vektp88j+TyUjp22iyYiChBeQ0QayWZQRD/s2gxmFR4deVRrZ7ZDeo7X5WcB VGHWNLbstUVkIV+rXVA+NwTFx9Tz8xcQVaZu716PAgSO67DvzsHrLdqTxx4SJ6De PukypFt8lXubBic/XJX/AC1fKvc8UgO0z3KvYt0oBiUihw8JcHI518JigCmIeUjW FP+4Aiwavndf4CymTvIAU2vFm85S94LACWtkjBneR8oTpyctUpbWMrQI86s7DeTB FsbLmGyVsfmXv5ykxGiIEwVtN8npCiMneWiD72JePgwtGA1Rpq8cr0zG5ak/Aryp 2m4JRyrLZwRjDHr0LA3QtPlyp/DyvozABBnH9FwyIA4D6v72W9ZXR3KJDMpqnn0r sqaloN9QLwuYnvw4ALzD62uDK2yzgjBzvALo9qivE/65uYHD0oYIREVFR/n/nz2k RUeccWJEM9LfNDlQ8WOd48Lq8sqi4oLjclWQKWVGXuYJHYZ/PhmoYo8bgwFp2eEh ieP0cV1HhULhc5GdOq4gHAh2wWK6L3WVHiGboh/gy/SzO5VIRg8=
=D7Ss
-----END PGP SIGNATURE-----

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On Fri, Dec 9, 2022 at 4:07 AM Arve Barsnes <[email protected]> wrote:

On Fri, 9 Dec 2022 at 11:55, Michael <[email protected]> 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

<div dir="ltr"><br><br>On Fri, Dec 9, 2022 at 4:07 AM Arve Barsnes &lt;<a href="mailto:[email protected]">[email protected]</a>&gt; wrote:<br>&gt;<br>&gt; On Fri, 9 Dec 2022 at 11:55, Michael &lt;<a href="mailto:[email protected]">
[email protected]</a>&gt; wrote:<br>&gt; &gt; To check the GRUB version of the second OS without booting into it, you can<br>&gt; &gt; grep for grub in its /var/log/emerge.log<br>&gt;<br>&gt; Or see what version is named in the /usr/share/doc/grub-
2.?? folder name.<br>&gt;<br>&gt; On the other hand, if the question is *really* about knowing if<br>&gt; grub-install has been run on one of the machines, I don&#39;t know if<br>&gt; there is a way. Probably look at change dates on the files in<br>&gt; /
boot/grub/?<br>&gt;<br>&gt; Regards,<br>&gt; Arve<div><br></div><div>Thanks to both of you for your responses. I appreciate them, although I</div><div>don&#39;t think they get as far down in the weeds as I was wondering about.</div><div><br></div><div>My
understanding of the boot loader - and maybe I&#39;m using the wrong</div><div>terminology so if I am someone please correct me - is that at the start</div><div>of boot BIOS tells the processor to read some part of the disk and it is</div><div>the code
read there that gets the whole process kicked off and</div><div>out of BIOS&#39;s control.</div><div><br></div><div>I&#39;m wondering about that first bit of code being written by installation</div><div>#2&#39;s update into the initial section of
installation #1&#39;s disk.</div><div><br></div><div>Rethink the picture a bit and make installation #1 Windows and </div><div>installation #2 Linux. Assume that after updating each install, and</div><div>further assume both installs made some very
minor change to their</div><div>own first bits of code on the disk, and assume everything still</div><div>boots correctly, BUT assume that one of the updates actually</div><div>wrote into the other install&#39;s initial boot code and replaced it with</

<div>their own because it was confused about which disk it was </div><div>supposed to put this on. How would I be able to determine that</div><div>this happened?</div><div><br></div><div>It&#39;s not totally a thought experiment. One machine I have

which </div><div>is dual boot recently complained that the original disk grub was </div><div>installed on had changed when in fact there hadn&#39;t been any </div><div>hardware changes and I had to carefully figure out how to </div><div>answer a
couple of questions. After the fact I started to wonder</div><div>about this edge case.</div><div><br></div><div>I think it comes down to reading what&#39;s on the disk with a </div><div>hex editor possibly but I know nothing about what to expect</div><

there.</div><div><br></div><div>Thanks,</div><div>Mark</div></div>

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On Fri, Dec 9, 2022 at 10:57 AM Michael <[email protected]> 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

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

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On Friday, 9 December 2022 18:39:33 GMT Mark Knecht wrote:

On Fri, Dec 9, 2022 at 10:57 AM Michael <[email protected]> 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.

-----BEGIN PGP SIGNATURE-----

iQIzBAABCAAdFiEEXqhvaVh2ERicA8Ceseqq9sKVZxkFAmOUa8EACgkQseqq9sKV ZxnzHA/+MvXzN76TXq6F8+Z+fUJ6w/+pEKrKwFaGmCU29MowfMydsB2GT2z0qMme gJqNYnxbM6RWWBujI5aMYkbDFlUjcXhzmDwwbLvwzEK9LTy3X9f4To/bVTICqKk1 eApqSzlygPNZ34Os/25cV915ClxYkZf07sSKoFzq2HOBFZwu4eWNfNkxgDcxBx/6 lBtMFKQiit++QKYOCKkGwA/CnCKvx9vHSB+MUFFDxBRO6WBtaD9Cr8av7jZXos2K a6NEwd9A8s48KHrjjRlisLGRe5FcnELpCrzuXNUYoqPkWjvnjplpNqPx6K6nb3x+ KKNLmj+SO6s88kXjePp+TrjVMT1j2nlia+R9UgKhnhSzcBuvawip7B77JtakNXSE Z4xPSLvFxswqjJlH0Mml8j0qO0q0m1T+9S9Quo/vVjjEBvgRneIEb7x8WxaqYTz2 JDsZl6aEg4TaN0OpEQisse/w31M3A4MUk5zouWm3o9gG+FR+hjCW4uwY9EyHQ33o y7aV7u3BZ+LoSx1q/fsR0haFRUn0t06hdBfwMyi+kK2TH9KKKiZyV6zA67yvaD70 CMtzJLmHVc+JwnlDzOaeCin+LTmaT/XBLPH+YHPmP1QxIdmI7Wcn/jOjfaCfxgui gvuce5XITnNa5bnUK/3LaOeR7lXgdfiz2D6NwG6byHkLeNwlKmw=
=6jgQ
-----END PGP SIGNATURE-----

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)