UEFI: Manjaro is missing

At LM terminal, first create a file /boot/grub/custom.cfg
sudo touch /boot/grub/custom.cfg
You can put your custom entries in 40_custom in /etc/grub.d but I don’t recommend it because

  1. you have to careful not to remove the header in that file, if you do, it will really mess up, not just your custom entries, but your grub as well.
  2. If you put a wrong or erroneous entry, it will mess up your grub as ‘update-grub’ won’t work then.
  3. If grub is updated (not update-grub, but grub version for example) or do a grub-install for some reasons, it will be lost.
  4. you need to ‘update-grub’ after doing 40_custom.
  5. People keeps recommending 40_custom despite my repeating this; and it makes me maad…:grin: just kidding. Who really cares.

Wait, you are removing LM?
So this is moot now?

No it’s not moot. I can not get manjaro going period. The problems are basically the same - manjaro’s grub just doesn’t play nice with my bios. Never shows up. I tried just going with manjaro and gave up. Tried LM just to see what would happen and was surprised to see it installed without a hitch. Then I made more room for manjaro, thinking I’d get LM’s grub to load it and then wing it from there. Don’t give up on me yet you’re doing great! I’m also learning a lot about EFI, so hopefully this will be of some use for a future blockhead like myself.

I think I miss the old days though. Red Hat 6.1 was a lot easier than this lol.

Okay, continuing…

After creating a file in LM’s /boot/grub/custom.cfg
Put entries there in that file and that’s it.
No need to update-grub, won’t disappear and any nonsense there won’t mess up your grub.
Remember it won’t appear in os-prober and in update-grub. It’ll be there when you reboot.

There are several entries that can boot up Manjaro from LM’s /boot/grub/custom.cfg. Put these and any of them will work. There’s more but these 3 are fine enough. My preferred is the first one.

menuentry "Manjaro Configfile "  {
    insmod part_gpt
    part part_msdos
    insmod ext2
    search --no-floppy --fs-uuid --set=root xxxxxxxxxxxxxxxxxxxxxxxxxx
    configfile /boot/grub/grub.cfg

menuentry "Manjaro Multiboot " {
    insmod part_gpt
    insmod ext2
    insmod chain
    search --no-floppy --set=root --fs-uuid xxxxxxxxxxxxxxxxxxxxxxxxxxxx
    chainloader /boot/grub/x86_64-efi/core.efi

menuentry "Manjaro Chainload" {
        insmod chain
        insmod fat
        search --no-floppy --fs-uuid --set=root xxxxxx
        chainloader /EFI/manjaro/grubx64.efi

xxxxxxxxxxxxxxxxxxxxxxxxxxx is the UUID of Manjaro OS partition
and xxxxxxx is the UUID of Manjaro $esp (the fat32 one).

Good luck.

[edited] - edited from --label to --fs-uuid: sorry. I normally use labels.
most people don’t.

That didn’t work. Has to be the bios. I completely understand your thoughts and learned a few new commands for EFI but as you can see, the manjaro EFI setup is there, but just not being recognized by the bios.

I’ll get to work on LM grub setup.

I can’t put this to bed. Here’s what I’ve observed.

After following the steps that gohlip outlined a few posts back, specifically the grub commands, booting to the manjaro install, doing a grub-install/update-grub and then copying core.efi to bootx64.efi, everything seems ok. If I then reboot and go to my bios’ EFI chooser (F12 on my lenovo), Manjaro is one of the options! Selecting it brings be back to my manjaro installation.

So at that point I feel like I’ve got it licked, and then disconnect my usb CD drive and restart again. The manjaro option is no longer there. Vanished.

I was perusing the arch forums and came across a post that mentioned there might be a whitelist of bootloader ID’s, so following their directions I reinstalled grub, following this command:

grub-install --target=x86_64-efi --efi-directory=/boot/efi --bootloader-id=“Red Hat Enterprise Linux” --recheck --debug

This moved it over to a different directory and, as expected, I had manjaro’s grub with an entry for Red Hat Enterprise Linux.

Of course, disconnecting the CD drive made that go away too.

My conclusion is one of two things:

  1. My bios is just wacked.
  2. Something about using a removeable USB CD writer is causing my installation to think this grub entry is dependent on the USB drive being present? Doesn’t seem likely as if I restart with the drive attached it doesn’t reappear.

I’m hoping to drop this mint installation. I remember liking mint at some point in the past but I’m finding their repo to be a bit conservative for my tastes. They have done an admirable job of making things work out of the box though.

Time to clean out all the loaders from (U)EFI (what we used to call the BIOS when there were still BIOS)?

Nice, clean, fresh, sparkling new install–like hopping out of the shower into a clean, warm, freshly laundered set of clothes?


There have been some situations here where UEFI boots have been problematic, some due to firmware and some due to tie-ups’ with Microsoft. Some have found the UEFI bootentry can only be ‘registered’ by going into the ‘heart’ (deeply) of bios setup (F2) and set up there.

I personally have no such ‘misfortune’ to be able to help much in this case. But recalling a few cases here, I’ve asked a member to list out his efivars (his system has GUUID not found in blikd) and it turns out his computer efi boororder keeps referring to Lenovo and Microsoft (despite deleting it in ‘efibootmgr’).

But I note in this case there is no problem in ‘registering’ Linux Mint and it is possible (though the OP did not mention it) it was done through the bios-setup or through a workaround in using Windows BCD circumventing the tie-up (if any) by Microsoft. If the OP can recall how Linux Mint uefi was set up, that will be good.

Anyway, comparing these commands (in any linux) would help
ls /sys/firmware/efi/efivars | grep ^Boot
ls /sys/firmware/efi/efivars

There is another command using ‘strace’ but I don’t know how to sieve through all the output.

[edit] - Not sure if OP still have windows.
For some situations where windows is really tied down to the uefi system (they should just return the fscking computer), there is a really rough hack where the linux efi file is renamed the windows boot.efi and it will boot the linux OS as the system thinks it is the windows efi file.

Well it has Windows 10 on it (it’s a new machine and I still need it), but this has to be a problem with the implementation in the bios. I say this because I just installed rEFInd to see what would happen.

Like Manjaro’s grub, Manjaro’s rEFInd doesn’t show up as an option in the bios either. So my modus operandi now to investigate matters is to boot into my manjaro-i3 install disk, select “Detect EFI bootloaders,” and see what shows up. Not surpringly at this point, I see all of the entries I put in before - my “fake” Red Hat Enterprise" manjaro efi, my standard Manjaro EFI, and now I see my rEFInd EFI as well.

I can, incidentally, choose rEFInd and am presented with their boot manager, and it’s working without a hitch.

I also assume it will pick up ‘manjaro’ (grub efi file) and boot that as well.
From the install menu, this or that should also work.

If you really want to, we can work out a bootable usb stick or sd card where it will have a boot menu and boot whatever things in your hard drive. But it’s a lot of work.

I got it working.

I think this all boils down to manjaro not being part of my bios’ whitelist of supported operating systems. So taking a hint from that earlier post of mine, where I named the manjaro entry “red hat enterprise linux,” I decided to try the same, this time naming it “ubuntu”:

grub-install --target=x86_64-efi --efi-directory=/boot/efi --bootloader-id=Ubuntu --recheck --debug

So guess what, I now have an entry for ubuntu grub, which is actually the manjaro grub installer. I’ve successfully tried it 4-5 times now, booting into all OS’s without a hitch.

I completely understand the need for security at the most basic level, but this “whitelist” may be a bit of overkill if it can’t be disabled physically when entering the bios. Talk about going against the principle of ‘free software’, or am I being preachy??

1 Like

Good. Do please tell us what computer this is so we all can avoid touching it with a 10 m pole.
And where do you get this whitelist ? What command will show this?
How does that compare with … ?

ps: it may still be a ‘space’ issue as reusing the same bootentry name like ‘ubuntu’ will not take up additional space in your bios memory. But you did clear up the other bootentries, right/
efibootmgr -b xxxx -B

It worked here.

I’m not convinced myself now that I’ve had a few hours of sleep. I have only seen one mention of this so-called whitelist of OS’s in the following blog:

I’m going to go back to check out the efibootmgr -v output to see what’s going on. Perhaps I never updated the order of the efi list, and the bios can only handle so many choices. Stay tuned.

As an FYI it’s a yoga 720. Got it for a steal from a guy here in Phoenix who bought a bunch from his company. Incidentally the i3 install is doing what it took me 3 full days to figure out with Mint’s i3 install. Lid/sleep, sound and brightness buttons all work out of the box, as does compton and conky. Nice.

Ok everything is working and looking as expected. I’m sure some of what I did was a bit reckless but as there was nothing (yet) of import on this computer, and I had a Windows recovery USB stick at the ready, I really didn’t care too much.

gohlip - a HUGE thanks for all of your assistance. You’ve been invaluable in helping me out here!

I still don’t know what the cause of my problems were but it may have been the limit on the number of EFI bootloaders my bios allows as you and others suggested, some problems in naming conventions, or a host of other things.

Ultimately I had quite a few directories in /boot/efi/EFI due to my many attempts to get things going. Using efibootmgr -b (entrynumber) -B I first deleted what I thought was an unneeded entry, followed by physically removing the directory itself from /boot/efi/EFI.

I had two manjaro EFI directories. One was named Manjaro, the other “manjaro” (quotes included)! I planned on removing both of them and re-running grub-install, but instead removed the Manjaro directory and renamed the “manjaro” directory to manjaro. This seemed to do the trick.

My remaining ubuntu grub was actually just another instance of manjaro - I must have deleted Mint’s grub by accident at some point.

At this point, my bios now only shows two choices for bootloader - Windows and manjaro. That’s good indeed.

One thing I noticed was that, with all of these options, the bios seemed to re-order the bootloaders, despite running efibootmgr -o 0002,0001,0005 etc. So it’s possible that all the work we did last night was somehow preempted by the bios. Again this may be due to the sheer number of entries. At one point I had:
2x fake manjaros
1xLinux Mint
1x Windows
1x Windows recovery
1x rEFInd

I think the next question is what happens when I update the kernel ;-D

Again, appreciate the help all. Hope my steps and missteps help someone out.

Good & happy to hear you’ve got it working and you’re welcome.
In some Lenovo’s, it is important to do this after the grub-install command

Cheers, take care.

Ok so now it’s not working. I’m too tired to put all details so I’ll summarize.
Attached cd drive to use gparted/debian cd. deleted Mint partition and grew Manjaro partition. No errors or problems.

Unplugged drive from USB and rebooted. Manjaro’s grub went missing again!

After numerous attempts at messing with efibootmgr, reordering efi load order, doing grub-install etc., I still don’t have it. I think what’s happening is that, when I plug in the SATA drive to the USB and enter the bios (so that I may boot from it), the bios does it’s own rewriting of the possible boot entries, erasing all my work. So it’s a bit of an endless loop there as far as I can tell. Will be playing some more. Stay tuned.

Just booted in. Executed the following:

grub-install --target=x86_64-efi --efi-directory=/boot/efi --bootloader-id=ubuntu --recheck --debug

And voila, I have a grub back! Doesn’t this mean my bios is ignoring certain entries, and accepting others?

Wait a minute…
Is your hard drive an external usb drive?

Then you will need to put a ‘–removable’ in your grub-install command.

Otherwise when you pull it out it will be lost.
Also even with the ‘–removable’ included, you may need to go to boot set up (F12) to select it after you have pulled it off and plugged it in.

Ah… that explains it. An external sata drive. Geez. All this time. :stuck_out_tongue_closed_eyes:

– removable that’s " - and - together, no space". 2 ‘-’.

1 Like

No no no. CD drive is external. I have to use it when I lose my bootloader so that I can boot from the live CD.

WHen I can no longer get to grub, what I do is boot from the live cd. WHen I get to the Manjaro CD boot screen I select “Detect EFI Devices,” which does a wonderful job (compared to my bios!) of finding a kernel on hd (0,1) /boot/manjaro from which to boot.

The moment I select it, and start loading from the hard drive (I usually see soemething like version 237) I yank the CD drive from the USB port in hopes of it not being seen by manjaro. However, it doesn’t make a difference, my efibootmgr -v output is monstrous, including multiple entries for the USB CD driv.

I’m not messing with you - I do the grub-install command and name it manjaro and it doesn’t stick with my bios. I name it ubuntu and it’s there for life. I posted to the lenovo forums to see if they can lend any insight into what’s going on.

I suppose the next experiment is to plug that drive back in to see what happens to my ubuntu grub. I’m a bit frightened to do so.

Well, ok. Got it.

There’s a few on Lenovo here and having boot problems of some kind.

Forum kindly sponsored by Bytemark