Grub, yes in general but also regarding neon

Help
1

I use Linux for quite a while as my main OS for daily work, started of in 1995.

For many years I’m a fan of KDE, however, mainly kubuntu. Right now I’m hanging kind of in the middle between kubuntu and KDE neon and I’m not sure whether I can get any of them to the place where I would like to have them. However, that’s a different story.

For some reasons I’m playing around with Linux installs on external SSDs. The advantage of this is that I can take my system with me where ever I go and if I have a system that allows me to boot from USB, I can use it. Best of it is, I can boot the SSD even on my MS Surface. It’s a bit of an awkward procedure, because I do not want to got through the trouble to create my own kernel image with a signature that would be accepted by MS. Anyway, it works and that’s fine with me.

Right now, I have an SSD with KDE neon, kubuntu and Mint installed. Mint did misbehave in the install and installed grub on the internal SSD of machine which I used for the setup, so the USB SSD was no long accepted as boot device after the install. Additionally installing KDE neon did fix this, which is of course nice.

However, regarding the boot menu where I wanted to be able to chose the system which I actually want to use (while I’m writing, I use KDE neon) KDE neon is quite stubborn. At least it took me this afternoon to convince KDE neon (it was the last install I did so I only had only the boot menu created by KDE neon), at least I could not figure out how I possibly could boot one of the other installs to fix things. So I was stuck with KDE neon.

What I can safely say is that basically everything you can find on the Web or on Youtube on this is not completely wrong but not really helpful.

Adding
GRUB_DISABLE_OS_PROBER=false
does(!) create some entries in /boot/grub/grub.cfg . However, they do not show up in the boot menu. Although I did not really try to verify this my interpretation is that setting the variable above with false creates the entry but on startup os-prober is not really used, so the additional entries in grub.cfg are ignored. However, I do not want to speculate because the Windows install found by os-prober was actually listed.

To get the menu entries in the boot menu, for now the only way I know is to manually edit /boot/grub/grub.cfg (although the content of the file says that this should not be done). I had to move the entries for kubuntu to the /etc/grub.d/10_linux section AND delete that prefix osprober- from the menuentry_id_option. For kubuntu this did work. Mint crashed on startup with the entry created by KDE neon. I checked the grub.cfg which Mint had created for its own install and saw that the KDE neon entry was only to 70-80 % correct. When I added the missing lines Mint could be booted, it was a bit slow but it eventually came up.

The reason for my post is no, to possibly get some answers:

  1. Why does KDE neon not use the os-prober properly on startup when I set the variable in /etc/default/grub like shown above (which is the main answer to the problem when you as google how to fix the issue with missing menu entries).
  2. I understand that dealing with other installs is not a completely easy task and I do understand that people can run into trouble with Windows installs. However, why do fight Linux distros each other?
  3. Is there at least a bit more elegant solution to what I use now because I of course know that when /boot/grub/grub.cfg is newly generated I have to apply my changes again (which is most likely on every install of a new kernel for KDE neon and of course also on the upcoming distro upgrade)?

I put this a question for help because I’m not sure whether I could call it a bug. However, it smells fishy.

2

Correct. os-prober doesn’t run when the system boots, it runs when the GRUB config is updated. So, with GRUB_DISABLE_OS_PROBER=false, when you update the config, other installed OSes will (theoretically) be found and added to the configuration.

I’ve also seen cases where one Linux OS doesn’t seem to detect another properly, but haven’t really got to the bottom of them.

3

I don’t think it isn’t working,

Grub’s os-prober is only run after updating grub, either when a kernel is installed, or manually running sudo update-grub.

Also, with three OS installed, which OS’ grub are you actually booting with?

Just because you installed Neon last, that does not automatically mean it was set as the main boot option, that can depend on the EFI implementation on the PC.
When you are moving between machines, the other systems, their EFI might be picking up a different OS.

On EFI, each OS install has its own boot loader, so you may need to use the computer’s bootup hot key to select the desire boot option, or set it in your BIOS.

A way around this might be to boot each OS, make sure os-prober is enabled there, and run update-grub in each so that you get all OS in each one’s Grub. This can tedious as you need to do this after each kernel update or at least regularly.

Me, when I used to do this sort of thing, I just used my computers’ boot hot keys to select the desire OS.

4

I’m aware that os-prober is running on update-grub. However, I admit I do not completely get what grub is doing at startup. At least it is not what I would expect.

You ask which system I use to boot. I’m pretty sure that is neon’s grub install. And this is not only my conclusion from the fact that neon was the last Linux install which I did, My main argument that it is neon, is that, when I boot form the USB SSD, I get the neon boot menu presented. I know that it is neon’s boot menu because I have additional neon installs (without any other Linux system in their direct access) and they present exactly the boot menu which neon was using before I did activate os-prober and applied my modifications.

Just to make clear how the setup on the SSD looks like. All three OSs share the same EFI partition but have a separate partition for /. /boot is sitting on the partition of / and the EFI partition is mounted to /boot/efi in all of them. So all OSs share the EFI partition but nothing else.

What strikes me is that my modifications to /boot/grub/grub.cfg (of the neon install!!!) are taken into account, when I put them at the right place with the modifications I mentioned. However, the output of “update-grub” (run in neon) contains menu entries which are not shown on startup. But all the answers which you get on the net regarding additional entries in the displayed(!) boot menu claim that all you need to do is activate os-prober and run update-grub. And I get this answer when I explicitly ask about how to do this with KDE neon. However, this answer is plainly wrong.

If I have another afternoon where I do not really know what else to do, I might try to do further experiments. It could be very well possible that the boot menu would actually change if I would do another trick, meaning “activate os-prober, run update-grub AND AFTER THIS run grub-install”. I could do this for each of the OSs installed and I would take a reasonable bet that I would get, depending on which OS I’m using different boot menus displayed. Only question would be would any of the Linux distros show the other ones and would any of them create correct menu entries which actually work for all of the other Linux installs. For neon it is clear that it is not able to do that because when I tried to use what neon provided, Mint crashed miserably on startup …