I usually use several Linux distributions on one disk using multi boot. I always install EndeavorOS last. The problem is that with other Linux distributions, every Grub package update overwrites the Grub installed by EOS, either for BIOS or UEFI systems. The question is how to bypass this in general with Linux distributions, install Grub at the beginning of the partition of the given system, so there is no overwriting, the originally installed Grub remains. Otherwise, in all such cases, Grub must be reinstalled from EOS, which is inconvenient. I saw an example of this in the openSuse installer, that Grub can be hidden, so to speak, i.e. on a machine with a BIOS system, it can be installed at the beginning of the partition of the given āforeignā Linux distribution instead of the MBR. In other distributions, however, I have not come across such an option, the installer installs Grub in the MBR by default in the case of BIOS.
Most of the solutions that come to my mind involve not using grub at all - as I also couldnāt get it to ignore āotherā distroās interference (not to mention mangling). It IS possible to alter the grub config on other systems to ignore os-prober, which can help - but it will still attempt to hijack boot priority in many cases.
- Learn to use efibootmgr to reset the boot priority as you wish
- Perhaps your BIOS allow a similar re-ordering
- Switch to rEFInd as a boot chooser - what the other distors do is ignored then.
There are a number of ways to gain rEFInd knowledge, starting with accessing our own Wiki @ discovery.endeavouros.com Several users here are familiar with it and can help if neededā¦
I would suggest to disable os-prober and efibootmgr in all the other OS:es.
Let EnOS Grubās bootloader to be in charge of the multibooting.
Thank you for your answer. Yes, in some cases the BIOS allows you to change the order. Iāll be honest, I havenāt really delved into the use of rEFInd yet, although Iāve read about it several times here on the forum. If it has this advantage over Grub, then itās worth using it. I guess, as the name implies, itās an alternative to Grub only for UEFI?
Most systems these days are EFI capable - but yes, this is mostly a limitation on using rEFInd. AFAIK, the only non-EFI thing it can handle is finding and booting a Win system that isnāt EFI.
As for checking out using rEFInd, checking our wiki shows how 2 commands should get you up and running - and one of them is installing the software! Easily bypassed/ignored/removed if you donāt like it, too.
Thanks, I didnāt even think of this simple solution. It just occurred to me that there is an exception to this problem: MX Linux is also installed on my laptop in addition to EOS, and updating Grub on MX Linux does not affect Grub installed by EOS. On the other hand, updating Kubuntu Grub will overwrite EOS Grub every time. So I notice that the problem is distribution dependent.
On a second thought, what I suggested above is what I have used for UEFI booting.
Not sure if it would work on MBR systems.
Perhaps you could prevent Kubuntu to run itās grub-install (grub2-install ?) for not overwriting the MBR each time the Grub package is updated.
Or just uninstall Grub(2) package in Kubuntu?
Please note that I am not having a multiboot with any debian/ubuntu based system at the moment so I canāt verify if this āfrom-top-of-my-headā suggestion would work.
If there is no other much better tested solution, then the ādirtyā method remains, i.e. reinstalling grub from EOS after each grub package update on the other OS. In such cases, on Ubuntu-based systems, the EOS-related menu entries in the grub configuration file must be rewritten anyway, because Ubuntu also interferes with this. (initrd initramfs)
You could also keep using Kubuntuās Grub and add a /boot/grub/custom.cfg.
Just copy over the entries from your EnOSā grub.cfg into this file.
This should add EnOSā boot entry to Kubuntuās Grub boot menu.
PS. Or perhaps better still to add EnOSā boot entries in /etc/grub.d/40_custom in Kubuntu.
I read what you wrote in your blog post. This is a really informative write-up on this topic, thank you. One lesson from all of this is that each distribution handles grub a little differently.
Am I correct that with this solution, the contents of Kubuntuās custom.cfg file will not change each time the Kubuntu grub package is updated?
Iām not sure I understand what you mean. Would kubuntu grub the main one? However, with my approach the main idea is that the main grub delegates to the grub of the other distro
As far as I know, file custom.cfg should never be changed by package updates.
But who knows about the futureā¦ 
Correct. Though, assuming that you would run os-prober on Kubuntu to detect your MXL, I guess you will be getting a couple of extra ānon-functionalā boot entries for EnOS in its grub.cfg anyways.
I think still your best bet would be to let the Grub from either EnOS or MXL to be in charge and then do away with Kubuntuās Grub altogether.
If I remember correctly, MXL uses its own modified Grub capable of generating correct menu entries for Arch (-based distros).
Thank you, each comment was valuable. Returning to the original question, therefore, we can state that the different Linux distribution installations prefer to install grub in MBR (for BIOS machines), and is not possible for Grub to be installed on the front of the partition instead of MBR? Canāt this operation be done later after installation? As I mentioned, I only saw in the SUSE installer that you can choose where the grub should go, and I used this opportunity.
If my memory serves me right, you could choose to install Grubās bootloader into the root partition in MXLās installer too.
It is marked as āfor advanced (or expert) usersā. I guess, meaning that you should know that you would need another systems bootlader to be installed in the MBR of the disk for being able to boot your MXL as well.
If I am not mistaken, perhaps in a bios/mbr install of EnOSā, you could choose where to install the bootloade from a menu as well in Calamares.
Not sure how it is in Ubuntuās installer.
At any rate you would be needing one bootloader installed in the MBR of the disk, capable of booting all the systems installed.
Out of curiosity, did you choose to go with MXLās Grub?
https://neosmart.net/wiki/mbr-boot-process/
https://wiki.archlinux.org/title/Arch_boot_process#Under_BIOS
Actually, after all these years of using EOS (the other distributions are usually only installed out of curiosity and only as a test), I stick to the Grub of the last Linux distro installed, which is usually EOS, so I stick with it. That is, I choose either the dirty method after grub updates, or one of the useful solutions already listed in this topic.
PS. By the way, in partial answer to your question, when grub is updated on MX Linux, interestingly it doesnāt overwrite EndeavorOS grub (This laptop has UEFI anyway), even though it seems that osprober is also enabled on MX. That is, because of this, I do not necessarily have to replace the grub of EOS with the grub of MX. From this point of view, Kubuntu is the biggest troublemaker, which not only overwrites the EOS grub with its own grub when updating the grub package, but only uses initrd for kernel entries and simply leaves behind the initramfs used by Arch. In such cases, the grub entries in question simply have to be pasted back from EOSās grub to Kubuntuās grub. A third distribution, MX Linux, is good for this, because Kubuntu doesnāt even allow grub.cfg to be overwritten as root. I called this the dirty method, as @freebird54 described as a solution in this forum thread.
This topic was automatically closed 2 days after the last reply. New replies are no longer allowed.