On Friday, 9 December 2022 18:39:33 GMT Mark Knecht wrote: > On Fri, Dec 9, 2022 at 10:57 AM Michael wrote: > > On Friday, 9 December 2022 17:17:24 GMT Mark Knecht wrote: > > > > > 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.