How to get Manjaro back to GRUB control and command

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


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.


Stick to one OS


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. :grin:

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


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:


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:

  1. Bootorder and bootentries are efi variables, saved in the cmos. The bootentry points to some efi file.

  2. 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.

  3. 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.

  4. 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 :slight_smile:

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. :slightly_smiling_face: