I am attempting to install Arch linux to a new (and very crappy) HP Pavillion 15 Notebook.
This is a UEFI-based machine. After several swings at it, I have managed to get pretty far. Legacy mode is disabled in the system setup, and I have EFI-booted to the Arch DVD I burned, and progressed through both the Arch Beginner’s Guide and the more advanced Installation Guide to the point where I am installing grub.
While chrooted, I execute:
grub-install --target=x86_64-efi --efi-directory=/boot --bootloader-id=arch_grub --recheck --debug
This emits a ton of output, including:
EFI variables are not supported on this system
The first time I got to this point, I continued with the installation, not knowing if it was an actual problem. Turns out it was, as when I rebooted the machine no bootable medium could be found and the machine refused to boot. I was able at that point to go in to the UEFI setup menu and select an EFI file to boot, and the Arch Linux would boot up.
But I am now going back and reinstalling again, trying to fix the problem above.
How can I get GRUB to install correctly?
Answers:
Thank you for visiting the Q&A section on Magenaut. Please note that all the answers may not help you solve the issue immediately. So please treat them as advisements. If you found the post helpful (or not), leave a comment & I’ll get back to you as soon as possible.
Method 1
The problem was simply that the efivarfs kernel module was not loaded.
This can be confirmed by:
sh-4.2# efivar-tester UEFI variables are not supported on this machine.
If you are chrooted in to your new install, exit out, and then enable efivarfs:
exit modprobe efivarfs
(efivarfs used to be efivars, so if this returns an error try modprobe efivars)
…and then chroot back in. In my case, this means:
chroot /mnt
but you should chroot the same way you did before.
Once back in, test again:
efivar-tester
This will no longer report an error, and you can install grub the same way you did before.
grub-install --target=x86_64-efi --efi-directory=/boot --bootloader-id=arch_grub --recheck --debug
Method 2
You will get this error if you have booted using legacy and not the UEFI method. You need to make sure to either select the UEFI boot item in the BIOS menu, or select UEFI as the default boot method.
Method 3
I know, that’s very old thread, but maybe will help for someone.
Most guides suggest the same solution to mount virtual filesystems before chroot:
for i in /dev /dev/pts /proc /sys /run; do sudo mount -B $i /mnt$i; done
But now (maybe related to efivars/efivarfs changes) this loop skips one very special sub-mountpoint – /sys/firmware/efi/efivars and efibootmgr/grub fails.
So use this line instead:
for i in /dev /dev/pts /proc /sys /sys/firmware/efi/efivars /run; do sudo mount -B $i /mnt$i; done
Actual success story:
Debian with 4.9.0-5 (efivars) saved by Arch Linux live cd (picked just because can boot uefi out of the box) with 4.14.9-1-ARCH (efivarfs) just by bind-mounting /sys/firmware/efi/efivars
Method 4
Running Fedora 27, I needed to mount the efivarfs. I did this inside the chrootfs, however this still wasn’t working, as the boot entry was shown with efibootmgr – but after reboot it was nether booted nor was shown once back in the live OS.
What finally worked, was using grub from the live medium, drop to the shell, and enter
linuxefi /vmlinuz-<version> root=/dev/mapper/luks-<uuid> ro
initrdefi /initramfs-<version>.img
boot
From the normal OS booted, I could run grub2-install without chroot, and that worked.
I am not sure whether this was just an issue with my BIOS, or there is still something more generally wrong, but this is what made grub2-install run without reporting any error.
# Open encrypted root partion
cryptsetup luksOpen /dev/sda4 a4
mount /dev/mapper/a4 /mnt
mount /dev/sda2 /mnt/boot
mount -t proc proc /mnt/proc
mount -t sysfs sys /mnt/sys
mount -o bind /dev /mnt/dev
mount -t devpts pts /mnt/dev/pts/
mount -o bind /etc/resolv.conf /mnt/etc/resolv.conf
chroot /mnt
# run inside the chroot:
mount /dev/sda1 /boot/efi
mount -t efivarfs efivarfs /sys/firmware/efi/efivars
grub2-install
Method 5
After some hair pulling frustration, finally found the solution to this. In my case I have a preempt-rt kernel (5.6.19-rt11 (patched)) custom compiled and installed on my EFI system.
The issue come to find out is that the preempt-rt kernels do not have efi runtime active, hence the error.
The solution is so simple:
Add efi=runtime to your kernel parameters in /etc/default/grub configuration.
GRUB_CMDLINE_LINUX_DEFAULT="efi=runtime quiet"
Don’t forget sudo update-grub2 !
Method 6
I was converting my BIOS/MBR system HDD to UEFI/GPT without data loss
As said, I shrunk last partition to create new EFI System partition with gParted and formatted it to FAT32:
Number Start (sector) End (sector) Size Code Name 1 2048 40003583 19.1 GiB 8300 Linux filesystem 2 956772352 976771071 9.5 GiB 8200 Linux swap 3 40003584 893857099 407.1 GiB 8300 Linux filesystem 4 894054400 956465151 29.8 GiB 8300 Linux filesystem 5 956465152 956772351 150.0 MiB EF00 EFI System
I mounted this Partition as:
sudo mount /dev/sda5 /boot/efi
But after installing GRUB I also got same error
sudo grub-install --target=x86_64-efi --efi-directory=/boot/efi /dev/sda
I Booted with Legacy BIOS and of course didn’t have efivars, makes sense…
But after i rebooted my PC to change BOOT mode to UEFI Native, I was puzzled that my PC booted normally…
like GRUB UEFI, despite error, was installed OK
I executed grub-install again and this time it went OK.
Method 7
You can’t! Building and installing are two different things, the machine you build on must be uefi capable. If you want to use/install linux on uefi capable hardware gpt must already exist. You can build gpt/mbr on uefi but not both if your hardware uses old bios.
All methods was sourced from stackoverflow.com or stackexchange.com, is licensed under cc by-sa 2.5, cc by-sa 3.0 and cc by-sa 4.0