Suppose I have 3 Linuxes on the same PC. Let them be OpenSUSE, Debian, Manjaro.
The OS last installed commands GRUB.
So when I boot my PC I see Manjaro GRUB menu.
Suppose I have to roll OpenSUSE back to the saved Timeshift image.
In this case OpenSUSE gets the command over GRUB, so when I reboot my PC I see OpenSUSE GRUB menu (not Manjaro menu anymore).
After some major update Debian catches the command, and after reboot I see Debian GRUB menu.
I just want to get Manjaro back in command. When my PC boots, I want to see Manjaro GRUB menu not other OSes GRUB menues.
Is there any elegant solution? ) What shall I do?
Alot infos missingā¦
Are you using MBR or UEFI?
How many disks?
Installed all 3 Linux on just one HDD/SSD?
Edit: Not sure if this only works with Win OS, but possible look in grub at
GRUB_DISABLE_OS_PROBER=false
after saving the file
sudo update-grub
I think that this maybe should show all other installed Linux destributions.
If this is not working, maybe buy a additional SSD and install Manjaro and give your Bios boot priority to this SSDā¦ atleast with MBR that worksā¦ but i have no idea about UEFI.
Yes
Stick to one OS
2 Likes
Could you build a unified boot menu, like, have all timeshift snapshots of the three OSs on the same volume and point all three GRUBs there --?
Or exclude GRUB from timeshift. Then only an install would take over GRUB.
(If thatās dumb, sorry, coffee has not kicked in yet.)
There is a difference if is BIOS or UEFI boot, with UEFI it will be easier. In such complicated setup the only sensible solution will be to keep the 3-4 OSes on separate partitions, isolated from one another and unaware of the other, with their own boot and grub-s (although if os prober is enabled they might appear in each others menus, but that will not be what you want if you want to restore backups etc.). Be sure to restore the grub loader from every OS so that each writes its efi variables.
And then always boot with the key F12 (or whatever), so basically use the UEFI menu. Which will then lead to the grub menu of the particular os.
I use UEFI.
All three OSes are installed on the same SSD disk side by side but on different devices (partitions), and each one uses itās own grub, boot, efi partitions. But all of them see each other in respective boot menus. And yes, each OS has itās own partition for Timeshift snapshots.
I switched ON os-prober on Debian, I can see all 3 OSes now and Debian is now in charge of GRUB. The point is I want Manjaro to manage GRUB not Debian. So the question is how to put a particular Linux OS in charge of GRUB when booting? I think, if I roll Manjaro back to the last Timeshift snapshot, It will get back control over GRUB, but I wonder if it is possible to reach by some other means. I think, Of course the best way to have a stable system is to use just a single OS. But Iām experimenting and studying now.
If thatās the case then try changing boot priority in the UEFI, or select from the boot menu.
Indeedā¦putting multiple OSes on a single partition is likely to cause issues. 
As i said, donāt do this. You are misunderstanding some things. No OS is in charge of grub, unless you use a shared /boot partition and grub between the 3 OSes, which is a BIG mistake.
If you left the things on default on install time and did not become creative in the partitioning wizard, you only have one / (root) in each os. And each OS has its own grub. You can check it in gparted for example, but you should actually know if you did some custom config at install time.
You are just currently using the debian grub. It just probably replaced the default efi boot ently on the last update. They are all linuxes, they all have grub with same settings and os-prober. OS prober tries to see everything he can in every other OS on the disk. So you can boot manjaro kernel from debian grubā¦It will workā¦most of the time. It will stop working properly in many cases, such as if manjo is updated with new kernel, and update grub is not run from within the debianā¦Donāt do it, on the long run it is a recipe for problems.
Just hit the key in the uefi and boot that way. You should see the 3 os-es, if not, restore grub.
p.s. and yes, that means you get 2 different boot menus after each other (uefi and then OS XYZ grub), but that is what you want.
p.p.s. in a uefi boot, each OS has its folder and .efi file, but there is also a backup ādefaultā entry. Windows loves to rewrite it for example. So the debian update changed the uefi boot variable and/or maybe that default efi file too (i guess if you are really obsessed with this you can manually copy EFI/manjaro/grubx64.efi as EFI/Boot/bootx64.efi but it is not really needed). Depending on the UEFI it maybe tries to boot this (because you are not explicitly telling the uefi to do anything it uses the defaultsā¦), and since it is a cloning of the debian one it goes there. As i said, restore manjaro grub if needed, it will refresh the uefi variable, so you can go to bios and change the boot order (manjaro to the top).
AFAIK we still canāt use another distroās grub to boot manjaro. So more like if debians kernel was updated and update-grub wasnāt run in manjaro.
Donāt restore GRUB in that case. Timeshift restores it by default just to be sure GRUB works after the restore, so youāll need to manually uncheck it in the advanced options.
As @Teo mentioned above:
1 Like
If you want the Manjaro grub, from whatever Linux grub menu appears (other than Manjaroās):-
a) Select Manjaro to boot to.
b) Really need to aee the output of sudo parted -l. You say you have all 3 OSs on one SSD, that would suggest that they are installed on block device - sda -. That parted command will confirm this.
c) If so, run command sudo grub-update /dev/sda. That should make an entry in your UEFI for āManjaroā This needs to be 1st boot, and in many UEFI cases it will be placed as such. However you do need to check this. So boot to UEFI to do that. If Manjaro is shown as 1st boot, the job is done. Otherwise configure UEFIās boot section to put Manjaro as 1st boot. Save, and reboot.
There is an elegant solution . . . just have one system that has grub and os-prober installed on it. It sounds like you are doing what I did for many years, each install had its own bootloader and they would fight over who controlled the grub āmaster listā each time the system upgraded āgrubā it would float up to the top.
As one of the posters mentioned you can boot your installs from the āBIOSā of the machine using the f6 or whatever key it is. But having the grub menu to list the items is in some sense easier. On my '12 MacPro I have now 7 linux installs . . . I had Tumbleweed as the āmaster controllerā of grub, but recently they have moved packages making their grub handling . . . less stable, I moved it to my Leap 15.6 install, but the problems went over there. Now Iām thinking that Manjaro will become the āmaster of grubā . . . but first I have to find out what the command is to āupdate-grubā in Manjaro, so that for instance if one or two of the systems upgrade their kernel, that changes the grub location or selection of what it will boot . . . the command that Manjaro uses to do that would be handy. For the most part, my Manjaro install has been the most stable, so I havenāt really had to learn how to mess around with it, as I have had to with other systems.
All you would have to do is to boot the other non-Manjaro systems, remove grub and os-prober from them and then āupdate-grubā in Manjaro and . . . elegant Bob is your uncle.
One caveat is that as the last year or two Debian and Ubuntu systems have āadjustedā something in grub, so that they are the only system that shows in grub . . . so to do what you are doing, Debian would only be the āmaster of one.ā
In my newer '20 Sys76 laptop I also have three installs, but, as per Sys76 request, each system has its own /efi/boot partition, its own / partition . . . and two of them share a /home partition, with different user names/directories. Pop! is the OEM system that is a stack on Ubuntu, so unfortunately or whatever, Pop! canāt share its services with the other kids, so grub/os-prober are removed from Pop! and the grub comtroller is run from the Gecko rolling partition . . . tres elegant.
If grub somehow blows up I can boot any of the installs from the āBIOSā OR worse comes to worse, the SuperGrub usb drive that I have to boot the machine. Good luck on it.
One of my systems dual-boots Manjaro and AVLinux. Installer for AVLinux has an option to not install GRUB, so it cannot over-write Manjaro GRUB
AFAIK most Linux installers have option to not install GRUB, but I have never used OpenSUSE,
so GRUB may need to be uninstalled
2 Likes
Yes, much the same with UEFI when each OS resides on a separate SSD; or HDD. Itās possible that a new install or an upgrade to a given OS will change the boot order, however, this is easily corrected via the BIOS.
Each OS should ideally install an instance of Grub to its own ESP, on the drive on which it resides. One only needs to be familiar with which of these ESPās; and therefore Grub instances; is desired to be first in the boot order.
An additional side effect is having other working instances of Grub available if one is somehow borked, preventing direct access to an OS. This premise is arguably also true on non-UEFI systems.
In your scenario only installing the Manjaro Grub instance might be a way to reach your objective; assuming Grub is properly configured to detect and boot other OSās; perhaps targetting the kernel directly (in the case of a UEFI system), or chainloading another bootloader stub.
All that is a lot of work and potentially high-maintenance. Itās much easier to install the rEFInd bootloader alongside Grub. Although rEFInd is usable with both Legacy and UEFI-based systems, using UEFI exclusively would be the better choice, given your situation.
Refind is installable via standard repoās, and should automatically detect the efi boot capability of other OSās.
In my multiboot situation; albeit with separate SSDās, I typically bypass Grub completely; however, thatās up to individual choice.
This is likely due to OS Prober being disabled at boot; a relatively recent security precaution in mainstream distributions. To overcome that multibooting annoyance, uncomment the following in /etc/default/grub:
# GRUB_DISABLE_OS_PROBER=false
At next boot, previously undiscovered OSās should appear; as if by magic.
For 3rd or 4th time i am reformulating myself about efi boot:
-
Bootorder and bootentries are efi variables, saved in the cmos. The bootentry points to some efi file.
-
Bootloader are .efi files on Esp partition. It is per specification 1 per disk and shared between every os , althought making many esp-s usually works. It is definitely NOT a requirement to have separate ESP for each os and is actually not advised anywhere.
-
The bootloader .efi file from esp is executable that can do anything, what it usually does is starting to load other things from its os on its partition. This is the point where the second part of grub is loaded, and its settings are read from the config files of do particular os and menu ist showed.
-
According to this grub config and parameters, a kernel is loaded.
So the advise to use a grub from one os whith its version of the executable and settings, and parameters, to directly load the rest of another os, skipping step 2, may or may not work anytime. It can be enough that the 2 grubs are different versions and maybe at some point the configs will be incompatible so that grub executable X from os X fails to load os Yā¦because it should be loaded with different config.
Right now it mostly works because the grubs are probably the same, but there is no guarantee for the future. So the correct way to do it, is to play with steps 1 and 2 and leave everything on lower level strictly separated.
1 Like
No, it is not a requirement to have a separate ESP for each OS. However, when installing each OS to a separate drive, an ESP for each drive is usually created, regardless, as it should be.
If you are suggesting that multiple ESPs should not be created on a single drive; thatās not in question. Iām not aware of any scenario in which that could (or should) be considered. Only one ESP is created on any given drive, by design; unless there is a UEFI specification that Iām not aware of.
In a multiboot environment, contrary to your above statement that ā[having a] separate ESP for each OS is not advised anywhereā, it is in fact the widely recognised safest, or most trouble-free strategy [when each OS is installed to itās own drive].
Edit:- Naturally, only one ESP and associated boot loaders are used at a time.
In the case of Pop_OS! they recommended the separate ESP [in the same drive] because they load the kernel(s) into that partition . . . taking up a large amount of space, so their partition size is also larger than is normal . . . .
Do not concur on the recommend for rEFInd, there was a time when it was needed, i.e., when OSX was the only system using EFI boot . . . but now many new systems use EFI boot . . . rEFInd adds a layer of complication that isnāt needed. Grub, boots EFI based systems just fine.
And, in response to the āItās OK to have grub in each systemā . . . sure, with only three installsāif they stay the sameāthen the overlap wouldnāt be too problematic. It would only be if and when a new system was installed or changed, then it could get complicated.
In the case of the OP, since the grub ācontrollerā has moved several times . . . the ācomplicationā has shown itself, already.
Technically, as per specification, only one ESP may exist on each drive; though, Iāve sometimes seen additional vfat partitions created for the very scenario you describe.
Subjective, at best. One could argue that Grub is an unneeded complication;
when another option is available.
UEFI tends to default on all new systems.
Actually, if #GRUB_DISABLE_OS_PROBER=false remains commented, in /etc/default/grub of the other two Linuxes, and uncommented in Manjaro; when using separate drives; it should be relatively safe.
With all OSās on the same drive ā and in an ideal world ā one Grub to rule them all would be nice; but in practice, I imagine it allows the potential for much to go awry as each OS competes for dominance; which is something the OP wants to avoid, I believe.
With regards ācomplicationā, itās my experience that rEFInd adds a level of simplification, and redundance. Of course, it depends on the scenario.
Additional:- Installing or moving rEFInd to the fallback path esp/EFI/BOOT/ is also possible, and effectively dictates that rEFInd will load before other available options within the same ESP; which can be beneficial, when preferred.
That is what i meant. I run such setup but that still does not make it a good/recommended practice.
Maybe i misunderstood but i think the OP has everything on one drive. If they are on separateā¦he does not have anything to fix and support case at all, he just had to change the boot order in UEFI and/or hit a button every time. Which isā¦logical anyway and probably not a reason to start a topic lol 
You seem to have understood the OPās scenario. My initial comments were in response to a prior suggestion that separate drives were a better strategy, which is a given. The other comments continued from that theme.
It shouldnāt even be possible to have more than one correctly identified ESP on a single drive; admittedly, Iāve never tried. 