Fresh UEFI Install Won't Boot - EFI bootrecord keeps disappearing

Hey everyone,

I’ve got a fresh installation of Manjaro KDE (EFI) that won’t boot. Spent last night scouring the forums for anyone with similar experiences, and ended up going down several (very helpful) rabbit holes, but unfortunately came up with the same result.

I’m not in front of my system at the moment to run inxi but my desktop is a custom build with an ASUS Prime z270-AR mobo, NVMe SSD, and two HDD’s for /home and other extraneous data.

Here’s a lowdown of my troubleshooting steps and results so far:

  • Mobo is in EFI-only mode, compatibility for Legacy BIOS disabled. Fast boot and Secure boot are also disabled.
  • Installed Manjaro KDE using a GPT-formatted live USB in EFI mode.
  • System won’t boot, and the EFI boot record doesn’t show up in my BIOS boot menu.
  • Rebooted into the live USB, ran the following to get into my Manjaro installation:
grub> search.file /etc/manjaro-release root
grub> configfile /boot/grub/grub.cfg
  • Manjaro installation is intact and boots normally this way.
  • From the installation, I confirm that my EFI partition has the boot flag applied.
  • Then I run:
$ efibootmgr -v #EFI bootrecord for new Manjaro installation does not show up
$ grub-install --target=x86_64-efi --efi-directory=/boot/efi #grub install completes without errors
$ update-grub
$ efibootmgr -v #EFI bootrecord shows up now, marked for boot
$ reboot
  • No dice. System doesn’t boot, and rebooting back into the system through the live USB grub command line shows that the efi bootrecord is gone again.

Anyone seen this before? Thanks in advance!


Here I miss:

--bootloader-id=manjaro --recheck


1 Like

Just in case… can you confirm that you have Secure Boot disabled? I recently helped a user that had a similar motherboard and he thought at first that Secure Boot was disabled but later realized that no, it wasn’t. In these Asus models it seems you have to remove the Secure Boot keys from UEFI/bios to actually disable Secure Boot.

1 Like

Full disclosure, I’ve run through re-installation and variations on the above steps several times now. One of those times I did include both of those flags, but I will re-attempt once I get home this evening.

Yep, I do indeed have Secure Boot disabled. Blew out the old boot keys and the whole bit following ASUS’s forums documentation.

An odd thing I’ve noticed is that in the BIOS, the UEFI partition/bootrecord for the Manjaro installation doesn’t even show up in the boot menu. However, the UEFI records do show up for live USB drives, etc.

Do you have more than one EFI partition? (i.e. one for Windows and one for Manjaro)

1 Like

Nope. All Manjaro, no dual-booting.

Ok. Another one that I saw yesterday, try to add the entry with efibootmgr:

efibootmgr -c -d /dev/nvme0n1 -p 1 -L 'Manjaro' -l '\EFI\MANJARO\GRUBX64.EFI' -e 3

The important thing is to add it with EDD 3.0 (the -e 3 option). Change the command according to your actual devices: /dev/nvme0n1 is the hard disk device and -p 3 is the partition number of the EFI partition on that disk.

1 Like

Thanks, I’ll give it a shot tonight! Is there any reason why this doesn’t work out of the fresh installation? Does the Manjaro installer use the correct flags when creating the EFI partition?

I just saw yesterday that in some motherboards efibootmgr (or grub) can fail to detect the right mode to create the UEFI entry, so you have to force it. I don’t know if it’s going to help but you can try it.


Oh, wow! That might be my issue. Let me try it out and let you know!

Alrighty, so I booted back into my installation via the live USB grub hack. And I ran efibootmgr -c -d /dev/nvme0n1 -p 1 -L 'Manjaro' -l '\EFI\MANJARO\GRUBX64.EFI' -e 3. I also attempted using grub-install with the efibootmgr wrapper fix mentioned in the Arch wiki article you linked to, and I tried being more specific by assigning the --loader when running efibootmgr. However, neither of these work.

I did make sure to run update-grub after efibootmgr, too.

OK so, this is super weird.

For this whole time, I’ve been doing installations with manual partitioning because I have a separate internal drive that I want to use for the /home directory. The process I’ve followed is what’s outlined literally everywhere I can find:

  1. Create GPT filesystem
  2. Create 512MB FAT32 partition at the front of the disk, with boot flag and /boot/efi mountpoint.
  3. Create 8192MB linuxswap partition with swap flag.
  4. Create ext4 partition on remaining space with the "/" mountpoint and root flag.
  5. Create ext4 partition on separate drive with the /home mountpoint.

For kicks and gigs, I decided to let Manjaro’s auto-partitioner do its thing, and reinstalled. And what do you know, it shows up in the UEFI boot list and I can boot no problem. So then I went back into the live USB, and reinstalled with manual partitioning, this time leaving the FAT32 EFI partition alone except for reapplying the /boot/efi mountpoint to it.

And it still works.

The only differences I can find in the partition created by the auto-partitioner and the one I originally made are that:

  1. There’s a 1MB leading space before the EFI partition starts, and
  2. The partition is 300MB instead of 512.

Other than that, it’s the same. Grub contents are the same as when I created the partition. No idea why the EFI entry would stick for this one, but not for the one I created manually.

1 Like

I may be seeing the same thing except on a laptop. I’ve installed Manjaro about five times in recent weeks for test driving, checking out DEs, software packages and so forth. Since I know it’s going to be temporary I’d just go with default partitioning for the entire SSD. Never a problem booting and each installation performed for days as expected.

Except the last installation earlier today I manually partitioned and saw nearly the exact same thing described above: instead of a grub menu as expected the computer booted straight into Windows. No signs of Manjaro in UEFI BIOS or the system boot menu (F12 key). I thought I’d try another manual partition scheme tomorrow in the daylight.

The laptop has two separate 500 Gb NVMe SSDs – disk0 for Linux and disk1 for Windows. The two different EFI partitions were on their respective disks and Secure Boot is always disabled.

My partitioning was about as simple as it gets:

  • 512 Mb FAT32 for /boot/efi, properly flagged & mounted
  • 250 Gb ext4 mounted as /
  • no swap

It’s not a crisis and I have a workaround but I thought I’d share because I don’t think it’s anything to do with our hardware.

1 Like

The (gpt) partition type is important and not visible in that screenshot.
It needs to be EF00:

$ gdisk -l /dev/nvme0n1
GPT fdisk (gdisk) version 1.0.8

Partition table scan:
  MBR: protective
  BSD: not present
  APM: not present
  GPT: present
Number  Start (sector)    End (sector)  Size       Code  Name
   1            2048         1050623   512.0 MiB   EF00  primary
1 Like

Huh, well I guess that confirms I’m not crazy!

My first step in manually partitioning is to create a GPT filesystem on the target disk. And when I create a FAT32 partition with the /boot/efi mountpoint + boot flag on it, the Manjaro installer detects the partition as an EFI filesystem. So I’m pretty sure I’m doing that part right…

Same here.

I haven’t had a chance yet to try manual partitioning again. Just a shot in the dark – but I wonder if it’s how the ISO is burned. For Manjaro images I use Etcher on Windows.

This conjures up another scenario from about a year ago when I was dual booting Fedora with Manjaro. Fedora’s installer was unable to mount /boot/efi formatted as FAT32 with Manjaro’s installer. What got Fedora recognizing Manjaro’s EFI was re-creating it with Gparted.

Huh, interesting. I dual booted Manjaro and Windows about a year ago and didn’t have any issues like that. I unfortunately didn’t try re-creating it with Gparted, maybe you should give that a shot on your laptop!

Out of curiosity, what edition of Manjaro are you installing? I’m using KDE, and I used Rufus to create the ISO. When I boot into the USB, the Manjaro installer also shows “EFI” and “GPT” at the top of the partitioning options menu, so it’s at least detecting those correctly.

1 Like

Normally I use KDE and that’s what I installed when Manjaro didn’t boot. I’m using Etcher for Manjaro ISOs because once upon a time I had problems with Rufus and Manjaro images. Good to know it works for you, I’ll try it again. At least it has a GPT/MBR selector which is why I wonder if something could have gone wrong with USB sticks made with Etcher.

1 Like