The issue is the bios does not properly recognize boot loaders, whether they are Linux related or not. The bootloader I am using is rEFInd and it is not linux specific. It could be any boot loader you choose. The bios detects the disk as bootable and finds my bcfg entry in the refind directory, only if there is also an \EFI\boot\ directory with a boot loader there, then it seems to work OK - meaning it detects the disk as bootable only with the \boot directory, then it will honor the bcfg configuration stored in NVRAM. This is a bios bug and not Linux specific.It is how the bios determines if a disk is bootable or not.
So, if a boot loader is installed in another directory that is not called \EFI\boot\ and you add a boot variable through shellx64 with bcfg command, (or any other method) the bios will not recognize the disk as bootable and will not honor the NVRAM boot config variable pointing an alternate directory. However, as soon as a directory called \EFI\boot\ is added, with any efi bootloader there, it will then accept the disk as bootable and will find the refind boot variable entry and boot properly.
So this is not a Linux problem and has nothing to do with specific Linux distributions. I have tried Fedora, Ubuntu, Debian, and they all create EFI entries that are not in \EFI\boot\ and hence will not boot.
Just to clarify, I can put shellx64.efi in a \EFI\tools\, add a boot variable to NVRAM that points to \EFI\tools\shellx64.efi, and the bios will not find the disk bootable unless there is also some boot loader that exists in \EFI\boot\, then it will honor the NVRAM boot config. Again, nothing to do with Linux or any other OS.
As I stated, it is not the specific bootloader or OS, rather it is that the bios does not recognize a disk as bootable unless there is any bootloader in \EFI\boot\, then it recognizes the disk as bootable and then the bios will honor the bootloader specific NVRAM settings. If you don't get this keep reading. If you still don't get it I don't know what else to say. (this is a bios problem with this motherboard and not an OS or loader specific problem.) .. the rest is my diatribe at these wrong responses...
Refind works just fine, it boots the system just fine. (and Refind is not linux). Simply that there has to be an efi executable in \EFI\boot\ for the bios to recognize a disk as bootable. Then it will honor the NVRAM settings that can point to something other than \EFI\boot\ directory for the bootloader. My system boots fine with refined in \EFI\refind\ but only because I created an \EFI\boot\xxx.efi file.
Why do intel people keep thinking this is linux boot loader specific problem and should consult linux or other forums when the problem is the bios? PS, The bootloader is not linux! If I put a windows bootloader or shellx64.efi as the executable, but don't put it in \EFI\boot\, but create a proper NVRAM entry, will the bios boot?? probably not, it is a bios problem in recognizing bootable disks and using the NVRAM settings if the bios thinks the medial is not bootable.
Please re-read the problem if you still don't get it: The bios does not recognize a disk as bootable unless there is an EFI excutable in \EFI\boot\, then it will properly use the NVRAM settings to find specified bootloader in the specified directory. The fix is that the bios should look at the NVRAM settings and use that to recognize bootable media. (again, again, and again, this is not a linux and not a bootloader problem, it is a bios problem.)
Do I need to keep repeating myself any more? The bios will not recognize a disk as bootable unless there is a \EFI\boot\*.efi file, then it will say, Oh this disk is bootable, it will then enable the disk * whatever as a bootable media, and the bios will then properly use the configured NVRAM setting to point to a bootloader one chooses in whatever directory the NVRAM specifies. This has nothing to do with linux. And it has nothing to do with the specific bootloader of choice. It is clearly a bios problem recognizing bootable disks and using the NVRAM settings to determine a disk bootable. Got it?
As mentioned and explained by me, this is NOT a Linux issue, it is a BIOS problem.
The boot loaders all work just fine. It does not matter what the boot loader is. Hence this can not be a Linux issue, or loader issue. It is a bios issue, where the UEFI BIOS is not using boot NVRAM entries unless there is a boot loader located in \EFI\boot\, otherwise it does not detect the media as bootable, and then subsequently ignores the NVRAM entries that point to that device. If there is any boot loader in \EFI\boot\, then the BIOS will check the NRAM settings for that device, and will load the EFI loader in the directory specified by the NVRAM entry. Hence, the fix has to come in a change to the UEFI bios and how it uses NVRAM entries to detect bootable media.. Why is this so hard to understand? That it is NOT a Linux problem or loader problem, it is a motherboard UEFI BIOS problem.
What if all I want to load is shellx64.efi, which I believe is an Intel based shell. Does that mean it is an Intel shellx64.efi issue, or the fact the NVRAM setting are not being used because a loader was not put in \EFI\boot\?
You are correct. It is a problem but since there is a easy solution and Intel only supports Microsoft Windows, then it is best if we continue to use the solution, and not beg Intel to fix the problem, because they don't want to spend time on fixing something that they don't support.
1 of 1 people found this helpful
Hi - I have this same motherboard with archlinux booting without any problem under UEFI - though I made sure that I updated the BIOS to the current latest version before trying to install arch linux using UEFI. Some earlier versions of the BIOS certainly had bugs. It all works perfectly well now using rEFInd but I did have to make sure that I understood how to configure rEFInd, and how to get the boot files in the right place -and set up corerctly. I have an SSD with the system area on it, and a /boot/EFI/ partition formatted as VFAT (which is required to be a UEFI ESP), as well as a /boot/ partition which is a directory within the root (/) partition as ext4. The kernel files (initramfs and kernel) are in /boot as written by pacman. In order for rEFInd to read the /boot files which are ext4 it is necessary to have the rEFInd ext4 driver (from the rEFInd package) copied across to /boot/ as well.
Also it is important to have the /boot/EFI partition set up correctly with the boot flag. The disk is partitioned with GPT and not MBR partitioning. The arch wiki gives all the details. Look under UEFI in the wiki.
Also important was that I found efibootmgr failed to write correct entries to the NVRAM, which then would not boot, and I had to boot a rescue usbkey and use the efi shell v2 to write the correct NVRAM boot entry. Once that was done the system booted fine under UEFI using rEFInd. I have no other bootloader installed. When there are new kernels new entries are written to /boot for the initramfs and kernel and the system reboots without any trouble at all.
Checkout the arch linux wiki, as well as Rod Smith's articles at The rEFInd Boot Manager
Note also that I made a special UEFI bootable usbkey to do the initial install of archlinux - again the method to create it is in the arch wiki.
By the way Rod Smith has provided huge amounts of help to people having issues with UEFI boot on the arch forums at https://bbs.archlinux.org/ and in that forum you will also find a thread about rEFInd setup with this very same motherboard when I was trying to fathom out how to get it working too!
If you set it up correctly it works beautifully in arch linux. My system boots to the login prompt for KDE in 7 seconds!
I hope this helps.