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 …

5

Well, I guess I can shed a bit more light on all this now.

Short version: KDE neon does for sure something wrong. At least on my system. Full stop!

I cannot in detail say where things go wrong. However, for sure the KDE boot menu which is shown when /boot of the KDE neon install is used DOES NOT include ALL os installs detected by os-prober when update-grub is done in the KDE neon install.

My speculation: I guess it is that the actual problem is in the code which produces the boot menu shown at start-up. You ask why I think so. This boot menu looks completely different than the boot menus are shown by the kubuntu and the mint startup.

You ask why I’m sure about this. Well, easy, in the folder which is used for grub in the EFI partition the file EFI/ubuntu/grub.cfg is used to tell grub where to find /root and there to look for /boot/grub/grub.cfg where it can find the information necessary to present the boot menu and depending on the user’s choice go on what the menu entry says. The content of EFI/ubuntu/grub.cfg looks something like:

search.fs_uuid $UUID root hd#,gpt#
set prefix=($root)‘/boot/grub’
configfile $prefix/grub.cfg

where $UUID needs to be the value of the uuid of the partition where /root of a Linux install resides and h# and gpt# needs to correspond on the disk and partition number which refer to the partition which happens to have the given UUID (however, I did not try what would happen if UUID and hd#,gpt# would point to different partitions, so if you want to know you need to try yourself).

So instead of relying on the boot menu created by one of the installs, it is possible to switch installs by editing the first line of EFI/ubuntu/grub.cfg . In my case, I have three installs KDE neon, kubuntu and mint. I actually put three line in EFI/ubuntu/grub.cfg where I put two in comments (using # at the beginning of the line, which allows me to easily switch between the installs and check what update-gurb does to the install and the boot menu it creates.

Conclusion of all this: kubuntu and mint both present boot menus after running update-grub which include ALL visible os installs. KDE neon presents a boot menu for itself and Windows, even though all visible os installs are listed in the output of update-grub (so os-prober is running AND creates respecive entries in /boot/grub/grub.cfg).

However, I already wrote that KDE neon fails to boot mint even with manipulated /boot/grub/grub.cfg (Yes, I already wrote that it is possible to force KDE neon into presenting a boot menu entry for mint. However, it is a senseless manual manipulation of /boot/grub/grub.cfg). It was interesting to see that kubuntu agrees with KDE neon on this. kubuntu creates and presents a menu entry for mint. However, if you try to use it mint crashes on start-up.

So mint is kind of picky regarding /boot and insists that it only wants to use its own one for what ever reason, I could not tell. However, mint is also the only install which creates and presents a boot menu which allows to boot into all visible os installs (in my case it is 5 installs KDE neon, kubuntu, min, fedora and Windows where fedora and Windows are sitting on a separate disk (with respect to the other three)).

So as a final decision for myself, if I want to easily switch between the installs I do have to use what mint produces in its own /root and use this for startup! Full stop for now.

6

This is why I no longer dual boot anything. You will end up with conflicting Grub and efi partitions/firmware. The UEFI standard only allows one active EFI partition on a system, which means it will share the first installed EFI partition (often Windows). I have moved to a paradigm where I install everything but my daily driver (Neon) to a fully portable USB external drive. To switch to a different distro I just plug in the USB and boot. No shared grub, no shared EFI. No problems. Keep everything internal unmounted and it will never touch the installed internal distro.

It is important to remove the references to the already installed internal distro otherwise you risk forcing the USB external to always be plugged in. There are a variety of ways to do this. Usually I just remove the internal drive, then install to the external. You can also “trick it” by removing the boot flags from EFI and /Boot, then installing onto the external and it should write a new EFI to the external and install grub appropriately. This comes with obvious risks.

7

This is not true, the UEFI specification clearly states:

UEFI does not impose a restriction on the number or location of System Partitions that can exist on a system. (From UEFI 2.10, section "Number and Location of System Partitions).

Restrictions might be introduced by your firmware or by operating systems though. As far as I know (I don’t use Windows at all), Windows will accept only one ESP and might act unpredictable if there exist more.

Linux ususally doesn’t have a problem with multiple ESPs. During installation of the OS you need to use manual partitioning and specify the ESP you want to use explicitely. The mount point needs to be set to/boot/efi.

I myself have two drives in my system, each of them have an ESP. On each drive an OS is installed and each OS uses the ESP on the same drive it is installed on.

8

I’m glad to see that more people are joining the discussion.

From my experience I can confirm what mook765 writes. You can have multiple EFI partitions active, however, they have to be marked as boot devices to be active and can be deactivated by removing this property.

I can at least partially support this statement. It MIGHT be an issue. However, from my experience (if I remember correctly) kubuntu and KDE neon ignored the internal disk. After I installed Mint on the external SSD grub was active on the internal disc and the SSD had to be plugged in. If not grub did stop with its command line prompt, basically asking how to go on. I never figured out what I could use as commands to get Windows 10 up without the external SSD plugged in. Funny enough, when I did an additional install on an external device (this time KDE fedora on an SSD stick) the install of grub on the internal ssd disappeared. At least Windows 10 is now staring up without anything plugged in anymore. So the system definitvely forgot about Mint. I used a refurbished rather old system running Windows 10 for my experiments. It is possible that all this behaviour depends on the BIOS that is running on the system.

Anyway it is a bit of a pitty that on the one hand Linux distros do not seem to agree on how to deal with all this, i.e. they obviously at least partially use different code. On the other hand, it is also not really appealing that it is not really intuitive to control this behaviour better when in the set-up process. I consider this what we look at here as the most critical part of the Linux set-up process. And if people run into trouble in this step, they are most likely not abel to cope with it properly. I see in all this at least one reason why Linux does not succeed in the area of desktop PCs while it has huge success in areas where people are not involved with the stuff like we see in this discussion (if you do not see what I want to say, I mention Android, Samsung Tizen, HPCs, Web/Cloud(e.g. Synology) servers etc. pp.) I would say Linux is the most widely used system (even by people who hardly know anything else than how to handle their smartphone in the most basic manner).

So in the whole it is a pity that Linux is struggling so hard on desktops.

So two final comments on this:

  1. Layering would make sense for Linux, where grub would be the lowest layer that I would see. And at least on this on this lowest layer, it would be great if the Linux community could agree on a standard and ALL distors would comply with it.
  2. What KDE neon does or did is kind of the worst thing one could do. Putting effort and resouces into decorating the boot menu while this decoration does not add anything that would be remotely useful and, if this was not enough, messing things up with this decoration.
  3. Looking at what Mint does when it comes to using /boot, I would even suggest to rethink what grub does with respect to os-prober. Mint’s behaviour shows that it is basically not a bright idea to force people into just chosing one /boot when swiching between Linux distros. It would be better if grub make a choice if more than one device was listed in EFI/grub/grub.cfg regarding which /root it should use.

Why do I care?

On the one hand I like Linux a lot.

I plan to teach people how to use it, if I find guys who would be interested, which is hard enough.

On the other hand, I want to make a educated choice of why I’m using a specific install and for this I need to evaluate as many distros as possible. Luckily, I have a set-up where all data I really care about is residing on a private cloud, so I basically do not care which client system I’m actually using. So switching clients is almost no effort.