0

On my system, I have two copies of CentOS 7 installed, and one copy of Windows 10 Pro. Every system is bootable and works correctly, and is fully up to date (kernels, packages, the works).

When I run grub2-mkconfig in either copy of CentOS (one host called pingu, the other pinga, for reasons), a new grub configuration is created. Part of it is generated through the os-prober template.

The entries generated by grub2-mkconfig for the copy of CentOS I booted into and started grub2-mkconfig from are correct. That is, they have menu entries with lines like these:

linuxefi /vmlinuz-5.4.147-1.el7.elrepo.x86_64 root=/dev/mapper/pinga-root ro crashkernel=auto spectre_v2=retpoline
initrdefi /initramfs-5.4.147-1.el7.elrepo.x86_64.img

However, entries generated for the other copy of CentOS 7, will look like this:

linux /vmlinuz-5.4.147-1.el7.elrepo.x86_64 root=/dev/mapper/pingu-root ro crashkernel=auto spectre_v2=retpoline
initrd /initramfs-5.4.147-1.el7.elrepo.x86_64.img

(note the linux and initrd instead of linuxefi and initrdefi)

I think this is due to four lines in the /etc/grub.d/30_os-prober like linux ${LKERNEL} ${LPARAMS} (etc.) - but why would this be the case? Why does os-prober assume the other copies of Linux should always be started with linux instead of linuxefi?

Am I missing some setting or override that would fix this?

For now, I have simply changed these lines in 30_os-prober to have linuxefi and initrdefi, but that feels like more than a bit of a hack.

Grismar
  • 127
  • 5
  • 1
    This question appears to be off topic: We do not accept general computer questions. You may be able to get help on our sister sites [su] or [unix.se]. – Michael Hampton Sep 21 '21 at 08:00
  • Wild guess: Perhaps os-prober might start other UEFI-bootable Linux distributions by chainloading into that distribution's GRUB, with e.g. `chainloader /EFI//grubx64.efi`, but since you have *two copies of the same major release of the same distribution*, it fails to find/identify the "other GRUB" as "this is a separate OS instance", and just sees the kernel and initramfs files with no obvious UEFI bootloader to go with them. Then it drops out of the UEFI special case and tries to handle it with generic non-UEFI code... which gets it wrong. – telcoM Sep 21 '21 at 08:25
  • @MichaelHampton - I meant no offense. Did you say so because this is too much the user side of things? The workstation I'm talking about is actually part of a cluster of HPC nodes that we're reconfiguring, so I came here because it was more of a business setting. Is the content of the question actually off-topic? – Grismar Sep 21 '21 at 22:06
  • @telcoM the boot, swap, root and home for both installation are organised in two separate volume groups, is there something else I could have done in configuration to avoid what you're suggesting? Or do you think this situation is more or less unavoidable with two copies of the same major release of the same distribution regardless? – Grismar Sep 21 '21 at 22:08

0 Answers0