| 1 |
On Friday, 9 December 2022 18:39:33 GMT Mark Knecht wrote: |
| 2 |
> On Fri, Dec 9, 2022 at 10:57 AM Michael <confabulate@××××××××.com> wrote: |
| 3 |
> > On Friday, 9 December 2022 17:17:24 GMT Mark Knecht wrote: |
| 4 |
> <SNIP> |
| 5 |
> |
| 6 |
> > > It's not totally a thought experiment. One machine I have which |
| 7 |
> > > is dual boot recently complained that the original disk grub was |
| 8 |
> > > installed on had changed when in fact there hadn't been any |
| 9 |
> > > hardware changes and I had to carefully figure out how to |
| 10 |
> > > answer a couple of questions. After the fact I started to wonder |
| 11 |
> > > about this edge case. |
| 12 |
> > > |
| 13 |
> > > I think it comes down to reading what's on the disk with a |
| 14 |
> > > hex editor possibly but I know nothing about what to expect |
| 15 |
> > > there. |
| 16 |
> > > |
| 17 |
> > > Thanks, |
| 18 |
> > > Mark |
| 19 |
> > |
| 20 |
> > Before I venture a potentially wrong answer, could you please clarify if |
| 21 |
> > we are talking about a UEFI MoBo, or a legacy BIOS MoBo. |
| 22 |
> |
| 23 |
> The specific machine where this happened is UEFI. |
| 24 |
> |
| 25 |
> Thanks |
| 26 |
|
| 27 |
Without more information on the errors GRUB produced I can't comment on the |
| 28 |
specific experience you had, other than to say you can install GRUB on a |
| 29 |
different disk/partition than the one the OS is on. Perhaps GRUB complained |
| 30 |
about being updated from a different OS used for its installation? |
| 31 |
|
| 32 |
Anyway, let's briefly clarify the BIOS startup process you mentioned, if only |
| 33 |
to explain why I don't think this is related to the errors you mentioned. |
| 34 |
|
| 35 |
On legacy boot systems the BIOS code is quite limited in what it can do. It |
| 36 |
just jumps to the 1st disk, first sector (LBA 0) and runs what it finds there. |
| 37 |
This era of technology used the MBR disk partitioning scheme and the first |
| 38 |
sector contained the boot loader code as well as the disk partition table. |
| 39 |
|
| 40 |
Modern UEFI systems use more capable EFI firmware (a.k.a. BIOS) and normally a |
| 41 |
GPT formatted disk. This modern system does not require any boot loader code |
| 42 |
to be written in LBA 0. The boot loader code is part of the UEFI firmware |
| 43 |
itself and is capable of loading and executing EFI compatible 'applications' |
| 44 |
stored in the FAT 32 formatted EFI/ partition (ESP) on the first disk. GRUB's |
| 45 |
EFI executable 'grubx64.efi' stored in the ESP on the first disk is loaded and |
| 46 |
executed by the MoBo's UEFI firmware. |
| 47 |
|
| 48 |
If I were to hazard a guess, the GRUB error messages you received are not |
| 49 |
related to the BIOS init sequence, but the GRUB configuration. Probably some |
| 50 |
mismatch between the filesystem UUID, GRUB's root prefix and perhaps the |
| 51 |
PARTUUID between the current OS and the one used to clone/install GRUB in the |
| 52 |
OS at the beginning. You could try to decipher this manually, by running |
| 53 |
blkid, to list your partitions and their respective UUID and PARTUUID. Then |
| 54 |
editing grub.cfg and/or any files if necessary under /etc/default/ |
| 55 |
|
| 56 |
On the other hand, it would be easier to reinstall grub on the OS you are |
| 57 |
currently booted into, with 'grub-install' followed by 'grub-mkconfig' to |
| 58 |
update its grub.cfg file. This should straighten out any discrepancies. |
Archives