Bootloader installation error with side-by-side Manjaro

I’m using a Surface Book 2. I’m installing Manjaro GNOME side-by-side with an existing Manjaro KDE. I’m using a live USB for this install. I’m installing from calamares, and replacing the partition /dev/nvme0n1p5 with Manjaro GNOME

Here is the output of sudo calamares -d

...
[PYTHON JOB]: Found gettext "en_US" in "/usr/share/locale/en_US" 
    ..  Job description from pretty_name "bootloader" = "Install bootloader." 
[PYTHON JOB]: "Bootloader: grub (efi)" 
    ..  Running ("grub-install", "--target=x86_64-efi", "--efi-directory=/boot/efi", "--bootloader-id=Manjaro", "--force") 
    ..  Target cmd: ("grub-install", "--target=x86_64-efi", "--efi-directory=/boot/efi", "--bootloader-id=Manjaro", "--force") Exit code: 1 output:
 Installing for x86_64-efi platform.
Could not prepare Boot variable: No space left on device
grub-install: error: efibootmgr failed to register the boot entry: Input/output error.
WARNING: [PYTHON JOB]: "Command 'grub-install --target=x86_64-efi --efi-directory=/boot/efi --bootloader-id=Manjaro --force' returned non-zero exit status 1." 
[PYTHON JOB]: "stdout:Installing for x86_64-efi platform.\nCould not prepare Boot variable: No space left on device\ngrub-install: error: efibootmgr failed to register the boot entry: Input/output error." 
...

Here is the output of sudo fdisk -l

Disk /dev/nvme0n1: 953.87 GiB, 1024209543168 bytes, 2000409264 sectors
Disk model: SAMSUNG MZFLW1T0HMLH-000MU              
Units: sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes
Disklabel type: gpt
Disk identifier: DB6FB364-EE6E-7842-BD3F-F23E082DA781

Device              Start        End    Sectors   Size Type
/dev/nvme0n1p1       4096     618495     614400   300M EFI System
/dev/nvme0n1p2     618496  488900607  488282112 232.8G Linux filesystem
/dev/nvme0n1p3 1964494086 2000397734   35903649  17.1G Linux swap
/dev/nvme0n1p4  488900608 1660776447 1171875840 558.8G Linux filesystem
/dev/nvme0n1p5 1660776448 1964494085  303717638 144.8G Linux filesystem

Partition table entries are not in disk order.

... # Some other stuff about /loop and the usb partitions

Here is the output of sudo lsblk

NAME        MAJ:MIN RM   SIZE RO TYPE MOUNTPOINTS
loop0         7:0    0 121.4M  1 loop /run/miso/sfs/livefs
loop1         7:1    0 887.3M  1 loop /run/miso/sfs/mhwdfs
loop2         7:2    0   1.5G  1 loop /run/miso/sfs/desktopfs
loop3         7:3    0 775.6M  1 loop /run/miso/sfs/rootfs
sda           8:0    1  28.9G  0 disk 
├─sda1        8:1    1   3.3G  0 part /run/miso/bootmnt
└─sda2        8:2    1     4M  0 part 
nvme0n1     259:0    0 953.9G  0 disk 
├─nvme0n1p1 259:1    0   300M  0 part /tmp/calamares-root-zq06xj1k/boot/efi
│                                     /mnt/boot-partition
├─nvme0n1p2 259:2    0 232.8G  0 part 
├─nvme0n1p3 259:3    0  17.1G  0 part 
├─nvme0n1p4 259:4    0 558.8G  0 part 
└─nvme0n1p5 259:8    0 144.8G  0 part /tmp/calamares-root-zq06xj1k

So I have tried to mount the /dev/nvme0n1p1 partition containing the EFI system. It now lists the following folder structure, output from `ls -LRl:

.:
total 12
drwxr-xr-x 3 root root 4096 Jan 13 12:07 EFI
drwxr-xr-x 2 root root 4096 Jan  7  2021 Manjaro
drwxr-xr-x 2 root root 4096 Jan  7  2021 boot

./EFI:
total 4
drwxr-xr-x 2 root root 4096 Jan 13 12:07 Manjaro

./EFI/Manjaro:
total 0

./Manjaro:
total 136
-rwxr-xr-x 1 root root 139264 Jan 13 12:18 grubx64.efi

./boot:
total 148
-rwxr-xr-x 1 root root 151552 Jan  7  2021 bootx64.efi

When I power-off, remove the USB, and reboot, it automatically reboots into the existing Manjaro KDE partition. This is alright for now, but I would like for the GRUB menu to show up so that I can choose to boot into Manjaro GNOME. I also haven’t been confirm that the Manjaro GNOME system is working at this point. Although I suspect that it is other than the actual .efi file to boot it up.

Any ideas what’s the error here and what might be a solution?

Solved, TLDR:
Try deleting the dump-type efi variables as suggested by @megavolt. It didn’t work for me immediately, but it was almost certainly the biggest contributor here. Thank you to @andreas85 as well.

You can stop in grub with ESC

You may have a look into the arch wiki to grub

This error could have 2 problems:

  1. No space left on the EFI Partition
  2. No space left on the NVRAM.

I would rather say that problem 2 occurred here.

  1. chroot into the gnome installation
  2. run the command there again with a different --bootloader-id=

  1. Check the efivarfs of dumb files:
ls -la /sys/firmware/efi/efivars 
  1. Delete them if there.

Reset the whole UEFI to factory defaults if nothing helps.

@megavolt @andreas85 I’ve chrooted into the Manjaro GNOME partition using the following command sequence:

sudo mount /dev/nvme0n1p5 /mnt/gnome-partition
sudo mount -o bind /dev /mnt/gnome-partition/dev
sudo mount -o bind /dev/pts /mnt/gnome-partition/dev/pts
sudo mount -o bind /proc /mnt/gnome-partition/proc
sudo mount -o bind /run /mnt/gnome-partition/run
sudo mount -o bind /sys /mnt/gnome-partition/sys
sudo mount /dev/nvme0n1p1 /mnt/gnome-partition/boot
sudo chroot /mnt/gnome-partition

Then, once chroot'd in I re-ran the grub-install command with a different bootloader-id= and received the following error:

$ grub-install --target=x86_64-efi --efi-directory=/boot/efi --bootloader-id=ManjaroGnome --force
Installing for x86_64-efi platform.
EFI variables are not supported on this system.
EFI variables are not supported on this system.
grub-install: error: efibootmgr failed to register the boot entry: No such file or directory.

Here is the output of the ls command, just for reference. Not sure if this is impacted somehow because I am running on the Live USB

$ ls -la /sys/firmware/efi/efivars/
total 0
dr-xr-xr-x 2 root root 0 Jan 13 11:53 .
drwxr-xr-x 5 root root 0 Jan 13 11:53 ..

Update:

Mounted another directory then ran the efivar-tester from the chroot’d environment:

$ modprobe efivarfs
$ sudo mount -o bind /sys/firmware/efi/efivars /mnt/gnome-partition/sys/firmware/efi/efivars
$ sudo chroot /mnt/gnome-partition
$ efivar-tester
...
About to test one
testing efi_set_variable()
FAIL: "one"(line 128) (-1) set test failed: No space left on device

Update 2:
After mounting /sys/firmware/efi/efivars, I found a lot of dump-type variables with the ls -la /sys/firmware/efi/efivars command. I deleted them as shown below. Same error with efivar-tester, tough:

cd /sys/firmware/efi/efivars
rm $(ls | grep dump)

Update 3:

Ran the grub-install command again with some different options and got no errors. About to reboot, wish me luck.

$ grub-install --target=x86_64-efi --efi-directory=/boot/efi --bootloader-id=ManjaroGnome --no-nvram --removable
Installing for x86_64-efi platform.
Installation finished. No error reported.

@megavolt @andreas85
Update 4:

Last update tonight. When I boot without the Live USB plugged in, it defaults back to the Manjaro KDE distro. When I boot with the Live USB plugged in, and then navigate to the Detect EFI Bootloaders screen, it shows four bootloaders. However, only the one for Manjaro KDE boots into the desktop. The other three boot into the grub console. Additionally, the folder paths are a bit peculiar

1. (hd1,gpt1)/efi/Manjaro/grubx64.efi # boots to grub
2. (hd1,gpt1)/efi/Manjaro/boot.efi # boots to KDE desktop
3. (hd1,gpt1)/efi/efi/ManjaroGnome/grubx64.efi # boots to grub
4. (hd1,gpt1)/efi/efi/boot/bootx64.efi# boots to grub

Getting closer but not there yet

So it seems your UEFI is directed to:

Instead of 1. (hd1,gpt1)/efi/Manjaro/grubx64.efi # boots to grub

When you look into efivars, this should show :wink:
You need to change the path in your NVRAM from boot.efi to grubx64.efi

  • This may be possible with from within the command line.
  • You also can try to go into your UEFI, and there it may be possible to change the path from boot.efi to grubx64.efi

Since you run it with --removable it is a standalone installation and no grub.cfg is there; therefore no instructions for grub. That is the reason why it boots to grub shell. You should generate one: sudo update-grub or sudo grub-mkconfig -o /boot/grub/grub.cfg

@megavolt @andreas85 I’ve taken your suggestion and run the command to generate the grub.cfg file. First I mounted and chroot’d into the Manjaro Gnome partition. Then tried the commands:

# Tried this first
sudo update-grub
# Tried this next
sudo grub-mkconfig -o /boot/grub/grub.cfg

In both cases, it associates the .efi file with the wrong partition. Not sure, but here is an example output:

$ sudo grub-mkconfig -o /boot/grub/grub.cfg
Generating grub configuration file ...
Found theme: /usr/share/grub/themes/manjaro/theme.txt
Warning: os-prober will be executed to detect other bootable partitions.
Its output will be used to detect bootable binaries on them and create new boot entries.
grub-probe: error: cannot find a GRUB drive for /dev/sda1.  Check your device.map.
grub-probe: error: cannot find a GRUB drive for /dev/sda1.  Check your device.map.
Found Manjaro Linux (21.2.0) on /dev/nvme0n1p2
done

The output should also include /dev/nvme0n1p5. So now when I try to use the ManjaroGnome bootloader, it goes to the Manjaro KDE partition. Additionally, on boot it still goes directly to Manjaro KDE and skips the grub bootloader selection menu

Any further suggestions?

Update:

Still digging through this. I’m thinking maybe I should just install over the KDE partition. I have all my important files saved in a separate shared partition. I’m still open to suggestions for the next two days or so.

Update 2:
I just put together that now the efivar-tester command is no longer throwing an error about “No space left on device”. I tried running the default calamares installer again on the nvme0n1p5 partition, and it worked! I’m not sure exactly what did it, but I suspect it had something to do with deleting the dump-type efivars. Just updating because it’s always good to hear a success story

1 Like

I think there maybe hard codes of the path via firmware to a specific location. I have an HP and am wondering how to find out what the path is for the hard code on my system at the moment. I read the article in the arch linux wiki about the HP_elitebook about UEFI setup