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:
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.
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.
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.
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.
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.
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.
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.
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:
Create GPT filesystem
Create 512MB FAT32 partition at the front of the disk, with boot flag and /boot/efi mountpoint.
Create 8192MB linuxswap partition with swap flag.
Create ext4 partition on remaining space with the "/" mountpoint and root flag.
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:
There’s a 1MB leading space before the EFI partition starts, and
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.
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.
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…
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.
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.
