Crash during GRUB reinstallation "executing efibootmgr.."

My GRUB reinstallation crashes on

executing efibootmgr -c -d /dev/sda -p 2 -w -L manjaro -l \EFI\manjaro\grubx64.efi


I'm following the wiki instructions from

I'm using a Lenovo Ideapad 320 with a HDD and SSD. GRUB should be on /dev/sda2, manjaro on /dev/sda8. Every time I install Windows and subsequently have to reinstall GRUB, I run into this issue. Oddly, sometimes it works despite the issue. I update /etc/fstab (because Windows creates a new boot partition and I have to put in the correct GUID), reinstall grub, reboot (because it crashes), update grub and it's good to go. But not this time.

I boot the latest iso from my USB stick to chroot into the manjaro installation. Oddly enough, not only does the installation itself crash, but the whole computer including the live version of manjaro I booted from USB crashes and everything locks up. That's also why the best I have to offer is this "screenshot".

I tried the normal method and the alternative method outlined in the wiki. The --debug flag at least shows that it consistently crashes at "executing efibootmgr.." as shown in the screenshot, but that's as far as I've got.

I'm not exactly a linux expert and searching for solutions via google hasn't been fruitful. Any pointers at what might be going on?

I would personally try running that efibootmgr command by itself with the -v option

Try this.

1 Like

I would personally try running that efibootmgr command by itself with the -v option

running the same command as grub does with -v at the end just leads to the exact same crash with no further output

Try this. 2

Booting into the "real" manjaro installation works fine. Installing grub crashes at

Info: executing modprobe -q efivarfs

Interestingly, botting the live cd, selecting "detect EFI bootloaders" and then booting from /efi/manjaro/grubx64.efi works fine

As does running update-grub

GRUB still doesn't seem to actually be there, or at least part of it, as it's not showing up as a bootloader in the boot menu of my laptop.

I've tried reinstalling the GRUB package as well.

So far, I've actually wiped the drive, reinstalled Windows, tried to reinstall Manjaro (surprise, same error), and fiddled with the BIOS and disabled anything that remotely smelled like secure boot or similar stuff. Oh, and I also made sure it's not in legacy mode and uses GPT partitioning. And that the ISO is written to my USB drive in DD mode.

I do know that it worked with a 17.x image, and after all I was able to install Manjaro at some point.

I'll wipe the drive again and just install Manjaro in hope that it helps.

Did you do the 2 [Additional UEFI commands] in that link?

And further more, you might have a Lenovo that's tied in with Microsoft.
See the Lenovo link in that post.
Output of 'efibootmgr -v' might give an indication; but after you do the additional uefi commands.

1 Like

Yes, I tried those.

A completely fresh install with a wiped drive was also futile. That should also cover the

or to remove windows totally, and lenovo will look for another efi file.

part of the guide.

This is the output from

efibootmgr -v
sudo parted -l
sudo blkid
findmnt -s
findmnt /boot/efi

I'll give manjaro-kde- a shot. I'm pretty sure one of the 1.7.* versions worked and I'm kind of out of options so far. Since I used to be able to install it with an older build, I'm thinking it might just be a bug.

Let's this out of the way first.

There is no output. But I think it is just because your 'copy and paste' left out the output.
If it is not and there is really no output. shout out now. I'm a bit suspicious that your sda4 (your $esp /boot/efi) is actually the first partition and that is unusual for a gpt disk and is flagged as msftdata instead of boot,esp.

So lets flag it first (as root, sudo)

parted /dev/sda set 4 boot on

Of course, always verify first device mapping every time we do a command that specifies device mapping (lsblk -f, parted -l....).

Then repeat the grub-install/ update-grub commands and the 2 additional uefi commands.

Then check if 'efibootmgr -v' gives a manjaro output.
{note it did not in your last post}. It must.
When you reboot (anywhere, even a liveOS boot) , check if 'efibootmgr give the manjaro output or it was lost again.

If it was lost, I think most likely you have a Lenovo that is tied in with microsoft.
Lenovo's, if not tied in with microsoft, do not get a troublesome uefi bios hassle (like Asus or MSI) as far as I know.

ps: what's in sdb? A single msdos partition (1 TB) ntfs.
You have windows?
Any windows OS there in bios-legacy? or just a data disk?
If no windows, what is it doing there?

1 Like

sdb is a drive with a single data partition, yes. No Windows. I do dual boot windows and Manjaro, but as I've said I completely wiped the sda drive including Windows and just installed Manjaro, which didn't fix the issue.

Thanks for your help. I've installed already and the installation itself went flawlessly.

This semi related issue lets me think it's maybe something with efibootmgr v15.

And I'm stuck now with my laptop not recognizing the bootloader as detailed in the Lenovo stuff from your link. That lead me to reinstall Manjaro yet again, this time just for ■■■■■ and giggles I've used the 17.1.2 ISO but installed the latest efibootmgr via pacman before running the installation. Surprise, the installation crashes again. So at least I know that using the old efibootmgr helps.

So I'm thinking it's some sort of bug. Don't know how to really help with fixing it, although I'd obviously like to.

Is there an easy way to see what changed with each new manjaro ISO?

While I'm not too 'happy' with Manjaro's grub (but don't worry about it), I don't think it is the issue here (as long as grub version is 2.03.2-1 and above, it is now 2.03.4) as doing the grub-install and the 2 uefi commands will get it into the efibootmgr entries even if the the installation process does not.

I still await your reply to my previous post as that can shed more light.

1 Like

I don’t think it is the issue here (as long as grub version is 2.03.2-1 and above, it is now 2.03.4) as doing the grub-install and the 2 uefi commands will get it into the efibootmgr entries even if the the installation process does not.

I cannot run any of these commands as efibootmgr just crashes again.

Here's the current output:

I've removed the other drive btw.

Also, no output for efibootmgr -v because it again just crashes.

That said, at least right now Manjaro is installed and boots fine. I'll update all the packages and see how it goes.

E: Update didn't go well, for some reason the terminal doesn't function. I just updated everything through octopi, rebooted, and now neither Konsole or Yakuake open. I tried reinstalling them as well. I'll try one of the other 17.1.* ISOs.

Part 1
Have you done this?

1 Like

Part 2

Check that you have following packages installed. If not installed, install them.

1 Like

Do you use text blocks?
I always admire your perseverance and these very detailed explanations.
So here is a thank you in short text form :slight_smile:

1 Like

Part 3
Do this only when Part 1 and Part 2 is done.
This is an important part.

Boot up to installed Manjaro at sda2,
At terminal,

sudo pacman -S grub
sudo grub-install --target=x86_64-efi --efi-directory=/boot/efi --bootloader-id=manjaro --recheck --debug

Check if command gives output of manjaro


If yes continue..

sudo cp /boot/grub/x86_64-efi/core.efi /boot/efi/EFI/boot/bootx64.efi
sudo efibootmgr -c -d /dev/sda -p 4 -L "manjaro" -l "\EFI\Manjaro\grubx64.efi"

Recheck again that 'efibootmgr' gives output of manjaro entry.

At any point there is an error, print out error message.
Please do not just write 'crashes' unless your computer shuts down at command.

1 Like

Part 4
If satisfied, reboot.
If error or won't reboot normally,
tell us after you booted (the hard way) output of


Any manjaro entry or was that lost?
I asked this before a few times.
I do not understand the term "crashes"
Do you mean that after booting up and issue command 'efibootmgr' at terminal the computer goes to 'shutdown'? I don't think so. But if that is correct, say computer shuts down.

1 Like

I have done part 1.

The packages of part 2 are installed.

I cannot do part 3.

As I've said, efibootmgr just crashes. That means most of the time, the entire system simply freezes. There is no further output, moving the mouse or pressing anything on the keyboard doesn't do anything. If the entire system doesn't freeze, at the very least the terminal freezes. This can then be rectified by killing efibootmgr via KSysGuard.

Nevertheless, running efibootmgr doesn't give me any output.

Meaning, if I run efibootmgr in the console, the output is just this:

[root@manjaro]# efibootmgr -v

That's it.

Same if I would run the command from the GRUB installer manually, for example

[root@manjaro]# efibootmgr -c -d /dev/sda -p 2 -w -L manjaro -l \EFI\manjaro\grubx64.efi

This is the only thing I would see in the terminal after running that command, no further output, and the system simply locks up.

This however does not happen with 17.1.2, 17.1.4 and 17.1.7, efibootmgr works fine and does not crash with 17.1.2, 17.1.4 and 17.1.7. Only on 18.0.4 (at least as far as I can confirm right now).

Edit: 17.1.12 also installs just fine.

Another edit: Problem first occurs when trying to install 18.0, all 17.x ISOs are fine.

Let's first get your system right first (the urgent part).
More important but not urgent matters later.

Since you have got it working in 17.x.xx, install that and update from there.
I take it you have no further problem, but if you have, let us know.

I was about to ask you to do step 3 but just these commands

to see if any error and then do


to see if 'crash' still occur and if gives a manjaro entry..

Now the important (but not urgent) part.

Command 'efibootmgr' should not 'crash' or 'hang'.
Even with a badly/wrongly installed system.
At most it should give errors something like
efivar not found
$esp not found
target efi directory not found
and so on.

It is also strange that works and does not, in the same system.

I cannot think of any reason other than a bad download (of iso).
Anybody has any idea?
@AgentS ? (you have been quiet lately).



Well, I tested 18.0 and 18.0.4, I can't imagine having two bad ISOs when all the 17.* worked fine and there were no errors otherwise.

That said, I also tested it with 18.0.4 again. Installed 18.0.4 until the installation froze again, booted into the live cd, downgraded efibootmgr to version 15.1, reinstalled GRUB via the "Restore the GRUB Bootloader" guide in the wiki, and everything works perfectly.

Manjaro 18.0 is the first version that uses efibootmgr 16, that explains pretty well why the problem start with this version.

During this, I also discovered that I'm not the only one who has problems with efibootmgr freezing (IdeaPad 320-15IAP is the exact model I also have).

There they also state " However: efibootmgr should never freeze, even if something is missed or goes wrong.". Well, I can confirm that it in fact can and does freeze.

And here's now the final output of my working system, I hope everything is in order.

The link you referenced indicated the solution was to use shim (by using "grub-efi-amd64-signed") which is the 'microsoft-sanctioned key' that debian and ubuntu can use with secure-boot enabled.

Manjaro does not use any microsoft key and does not boot with secure-boot enabled. As I said, I suspected that your lenovo is tied in with microsoft but you have no problems with so I'm not sure about my suspicion, which I also mentioned.

But I noticed some peculiarities with your fstab. It happened in both your fstab outputs.
(And maybe it is caused by the installer, I don't know)
Can you go to your manjaro /etc/fstab (not livecd but the installed Manjaro OS) and print again the contents of its /etc/fstab (of your installation)? Please ensure nothing is left out or truncated.

At least you got in working now, right?

It finally seems it is an issue with efibootmgr (calamares was suspected as well until your last post).
@philm needs to know (if not already :wink:) . The 18.x ISOs have newer versions of installation utilities, so you have to use 17.x ISO for any installation/boot/UEFI related job, since I suppose/suspect you may have issues with installed package of efibootmgr.

What makes me wonder is

If this happens every time Windows installs/updates, it is awful!! If partitions are re-created all the time (especially system critical, like $esp), it is so close to some error that might eventually destroy something..
It might be a workaround (if you have windows installed, or even because vendor UEFI messes) to create another fat partition and use it as $esp for Linux/Manjaro.

1 Like

Forum kindly sponsored by