One system I have tested does not seem to work with rEFIND 0.4.5, though another has no issues. The working system uses an ASUS motherboard while the nonworking system is using MSI.
There is only 1 harddrive that is formatted with GPT using the gptfdisk contained on the archboot boot cd. The first partition is my EFI System Partition (partition code "ef00" and formatted as FAT32). The rest of the disk is a large XFS partition.
Now, when I add the rEFInd application to my EFI menu using
(# efibootmgr -c -l \EFI\refind\refind_x64.efi -L rEFInd)
this successfully completes and I can see it listed as the default in the boot order. On reboot, however, I get an error "Missing Boot Loader".
I have installed the rEFInd directory to /boot/efi/EFI/refind and it contains the refind_x64.efi binary along with the drivers and icons. I have also tried some of the alternate naming schemes like EFI/BOOT/bootx64.efi to no avail. What is curious is that this system worked with GRUB2-efi before using Arch Linux (I am currently booting using Debian Wheezy).
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
I've seen this type of problem before -- one of my motherboards tends to "forget" its NVRAM entries. I have several suggestions for what to try:
Install rEFInd as EFI/BOOT/bootx64.efi. On some systems, EFI/Microsoft/Boot/bootmgfw.efi will work. I recommend you try both of those options. (I know you say you've tried the first, but you didn't mention the second.)
See if a firmware update is available from the manufacturer; it could be that this is a bug that they've fixed.
You could try, from Linux, issuing an "efibootmgr -v" command to see what the firmware options are once you've booted. Perhaps there's something odd about them. (You might see something yourself, or you might need to post here for advice.)
You can boot a version 2 EFI shell program and use its bcfg command to manage your boot options. I've found that this works better on some systems than does Linux's efibootmgr. Typing 'bcfg boot add 2 \EFI\rEFInd\refind_x64.efi "rEFInd" ' should add rEFInd as item #2 in the boot list. (You might need to change the number and/or the path to the binary, of course.)
Try changing from FAT32 to FAT16; or try creating a FAT32 filesystem using something other than Linux. Although the EFI spec says that FAT32 is required on the ESP, I've run into one system that had problems reading some files from a FAT32 filesystem. Switching to FAT16 fixed the problem. This is probably a bug and/or an incompatibility between that firmware's FAT driver and whatever Linux's mkdosfs does to create a FAT32 filesystem.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
This sounds like a really good start to troubleshooting. Actually, I have had this issue with the board before though it worked to simply clear the CMOS and try again (this time it will not work).
Right now I'll start with the output of efibootmgr:
Nothing strikes me as particularly odd. I'm not sure what it all means but I assume HD(1,0,0,c3510801) mean the first harddisk, partition 1 (aka "0") and the other two values I'm guessing have to do with hardware identifiers. Anyway, the path is correct ("\EFI\refind\refind_x64.efi").
I'm curious if I should try the bcfg tool in my system's EFI SHELL. It seems that the firmware is seeing the changes made by efibootmgr -- it just isn't able to find the actual application. Would bcfg work "better?"
Also, I really want to update my firmware because, like I said, I have had this issue before when clearing CMOS worked, but MSI only provides an EXE of the latest build instead of a flashable AMI file... and I don't own any DOS boot disks to load that from. This is most frustrating as MSI used to release the AMI file zipped with the EXE.
Finally, I'll try using FAT16 or the Microsoft boot directory as a last resort. I do remember that when I had a Windows 7 partition that it placed the files there (but, again, the other files worked just fine at the time on a FAT32 filesystem in my usual directories). It is also my understanding that Microsoft has trouble booting from a FAT16 ESP, which would be problematic if I decide to install it later on.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Your BootOrder variable puts rEFInd at position #4. It's possible that one of the earlier items is taking over and bypassing rEFInd. You could try fixing this by adjusting the BootOrder (using the -o option to efibootmgr). If that doesn't work, you could try deleting the earlier items, or even delete all the entries and then re-create the rEFInd entry as the first item.
As I wrote before, bcfg works better for me than efibootmgr on one system, so it is worth trying; but I can't guarantee this will be the case for you.
In terms of the firmware update, you could see if FreeDOS (http://www.freedos.org/) would work; or you could try extracting the files from the .exe that MSI provides using unzip, unrar, or other utilities. (These self-extracting archives generally use common package formats and can be extracted in this way.) Check your manual, too; there may be instructions for doing a firmware update outside of DOS or Windows.
If FAT16 works on the ESP, you can always back it up and change it to FAT32 for the benefit of the Windows installer, should you want to install Windows in the future. Let Windows create the FAT32 filesystem, if possible; or if the switch to FAT32 causes problems for rEFInd at that time, you could back up again and switch back to FAT16. AFAIK, it's only the Windows installer that flakes out with a FAT16 ESP, so a temporary switch to FAT32 for installation should be all you'll need.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
1) On your first suggestion, I have what may be a silly question: if I run "# efibootmgr -O" to delete the boot order this is not the same as deleting the entries, correct? I am wary of deleting the actual entries using the -b/-B options, perhaps needlessly, in case that causes devices not to be recognized.
Still, I have tried setting the bootorder to set rEFInd at the first boot option (and GRUB2 at one time) and, like I said, it worked in the past sometimes but no longer does. When I reboot it simply forgets the order, however, not the actual entries.
2) My UEFI spec is version 2.10 from American Megatrends (MSI motherboard) but it does not include the "bcfg" program. Apparently, this is supposed to be part of the v.2.0 UEFI spec so I am curious why my firmware doesn't include it. Is there a way for me to boot a different EFI shell that will have this feature? For example, could I make an ESP, formatted as FAT16, on a USB device and place a shellx64.efi file on it in the EFI/boot/ directory and it would work? Again, sorry for my ignorance. All my information on EFI comes from your rodsbooks website and the scattered documentation on various wikis (I'm still learning).
3) I have emailed MSI with the hope that they can release the firmware in the way they used to -- a ZIP including the EXE, AMI and docs. The EXE cannot be extracted by unzip or 7zip and I am not sure I would have success with anything else (I remember a utility called cabextract or something similar). The EXE wants to be placed onto a USB key so that it can create its bootable device. I've tried cheating by using a virtual machine but it complains that the motherboard is not supported. Sigh.
4) Next I can try formatting the ESP as FAT16, though it strikes me as odd that this would be the issue if it was working before. I was booting UEFI Arch Linux last week on this board using GRUB2. I'm now using Debian, though Arch does not work, either. The EFI/Microsoft/Boot/bootmgfw.efi gimmick also seems odd to me as I never had an issue with my previous installation (I install Linux first and created all partitions from my LiveCD, so it wasn't Windows that initially set up the "working" installation).
A few side questions:
- What do you use to partition a "fresh" machine? I imagine that you might have an Apple laptop/tower, but do you use a particular distribution of Linux for any other machines? I'm curious if maybe I should use a specific LiveCD that has a different version of GPT fdisk or something.
- Do you have any recommendations of manufacturer boards that seem to work the best? I'm not really in the market myself, but I'm curious if any boards have been particularly finicky.
Thanks!
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Correct, the "-O" option to efibootmgr deletes the BootOrder variable but not the actual entries. You wouldn't normally need to use this, though; just use the "-o" option (lowercase rather than uppercase), as in "-o 3,2,7" to boot entry #3 followed by #2 followed by #7. This will change the BootOrder variable. The "-O" option deletes it entirely, so you'd need to use that followed by "-o" to set a new order. If you've changed the BootOrder and it keeps changing back, then that sounds like either a firmware bug or a weird interaction problem between efibootmgr and your specific firmware. This is the sort of thing where using bcfg in the EFI shell might fix the problem.
The EFI shell program is independent of the EFI version on the motherboard. All you need is the shellx64.efi file (or whatever the filename is) for a version 2 shell. See https://wiki.archlinux.org/index.php/Unified_Extensible_Firmware_Interface#UEFI_Shell for links to several shell binaries and instructions on using bcfg. One caveat: A version 2 shell might or might not work with a version 2.10 EFI; that shell is actually part of the EFI 2.3 system. (Yes, the numbering is confusing.)
The FAT16 workaround should not be necessary, but I've run into one system where it was necessary. On that system, the EFI seemed to be unable to read certain files. Unfortunately, these included the kernel (with EFI stub support) I was using, as well as some (but not all) of rEFInd's icons.
Calling the boot loader EFI/Microsoft/Boot/bootmgfw.efi is also totally bogus, but works on some systems that hard-code this filename, along with EFI/BOOT/bootx64.efi, as fallback boot loaders. One of my computers can boot this way, and I've heard reports from others who say they have trouble booting from anything but that filename. (IIRC, that was an HP laptop.) It could be that your system is alternating between working and not working because of some subtle difference between your attempts. EFI is actually comparable in size to the Linux kernel minus its drivers, so it's a pretty huge code base that contains numerous bugs. (EFI's seen much less use than Linux and so is still far from debugged.)
I try to use GPT fdisk for partitioning, but it's often easier to use something that's based on libparted (GParted or a Linux distribution's installer). I don't use Microsoft tools for partitioning unless I'm running tests that require it. In my experience, Microsoft's tools are very flaky. OS X's GUI disk partitioning tool is pretty restrictive, but I sometimes use it when dealing with OS X, since it implements various rules that OS X likes to see implemented on its disks.
As to specific motherboards, I have limited experience. Currently, I've got a recent ASUS board (a P8H77-I), which works well except for an interaction with a KVM switch that has forced me to install a separate video card. (That's not an EFI issue, though.) I've got a Gigabyte GA-78LMT-S2P (rev. 4.0) board with Gigabyte's hybrid EFI implementation, which is dreadful (see the linked-to page for details). I've also got an older Intel board that's so-so -- it's the one that gave me the weird FAT32 problems, and it seems to completely ignore the BootOrder variable.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
I now have it booting again. I think what ended up being most helpful was your suggestion to remove ALL the boot options and then create the rEFInd option.
The UEFI Shell 2.0 actually wouldn't run on my 2.10 firmware system, though I suspect maybe something else was the issue (some "assert" error -- but that isn't for this thread).
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
One system I have tested does not seem to work with rEFIND 0.4.5, though another has no issues. The working system uses an ASUS motherboard while the nonworking system is using MSI.
There is only 1 harddrive that is formatted with GPT using the gptfdisk contained on the archboot boot cd. The first partition is my EFI System Partition (partition code "ef00" and formatted as FAT32). The rest of the disk is a large XFS partition.
Now, when I add the rEFInd application to my EFI menu using
(# efibootmgr -c -l \EFI\refind\refind_x64.efi -L rEFInd)
this successfully completes and I can see it listed as the default in the boot order. On reboot, however, I get an error "Missing Boot Loader".
I have installed the rEFInd directory to /boot/efi/EFI/refind and it contains the refind_x64.efi binary along with the drivers and icons. I have also tried some of the alternate naming schemes like EFI/BOOT/bootx64.efi to no avail. What is curious is that this system worked with GRUB2-efi before using Arch Linux (I am currently booting using Debian Wheezy).
I've seen this type of problem before -- one of my motherboards tends to "forget" its NVRAM entries. I have several suggestions for what to try:
This sounds like a really good start to troubleshooting. Actually, I have had this issue with the board before though it worked to simply clear the CMOS and try again (this time it will not work).
Right now I'll start with the output of efibootmgr:
Script started on Sat Sep 29 14:49:39 2012
[Arch Linux: /]# efibootmgr -v
BootCurrent: 0006
Timeout: 1 seconds
BootOrder: 0000,0001,0002,0003,0004,0006
Boot0000 SATA3:WDC WD5000AVVS-63ZWB0 BIOS(11,0,00)
Boot0001 KingstonDataTraveler 2.01.00 BIOS(15,0,00)
Boot0002 IBA GE Slot 0200 v1321 BIOS(16,0,00)
Boot0003 GRUB HD(1,0,0,c3510801)File(\EFI\refind\refind_x64.efi)
Boot0004 Built-in EFI Shell Vendor(5023b95c-db26-429b-a648-bd47664c8012,)
Boot0006 UEFI: KingstonDataTraveler 2.01.00 ACPI(a0341d0,0)PCI(1d,0)USB(1,0)USB(8,0)HD(1,800,1e0b7df,a839f5bf-0377-419c-a365-447ab3b91d79)
[Arch Linux: /]# exit
exit
Script done on Sat Sep 29 14:49:51 2012
Nothing strikes me as particularly odd. I'm not sure what it all means but I assume HD(1,0,0,c3510801) mean the first harddisk, partition 1 (aka "0") and the other two values I'm guessing have to do with hardware identifiers. Anyway, the path is correct ("\EFI\refind\refind_x64.efi").
I'm curious if I should try the bcfg tool in my system's EFI SHELL. It seems that the firmware is seeing the changes made by efibootmgr -- it just isn't able to find the actual application. Would bcfg work "better?"
Also, I really want to update my firmware because, like I said, I have had this issue before when clearing CMOS worked, but MSI only provides an EXE of the latest build instead of a flashable AMI file... and I don't own any DOS boot disks to load that from. This is most frustrating as MSI used to release the AMI file zipped with the EXE.
Finally, I'll try using FAT16 or the Microsoft boot directory as a last resort. I do remember that when I had a Windows 7 partition that it placed the files there (but, again, the other files worked just fine at the time on a FAT32 filesystem in my usual directories). It is also my understanding that Microsoft has trouble booting from a FAT16 ESP, which would be problematic if I decide to install it later on.
A few observations and additional suggestions:
1) On your first suggestion, I have what may be a silly question: if I run "# efibootmgr -O" to delete the boot order this is not the same as deleting the entries, correct? I am wary of deleting the actual entries using the -b/-B options, perhaps needlessly, in case that causes devices not to be recognized.
Still, I have tried setting the bootorder to set rEFInd at the first boot option (and GRUB2 at one time) and, like I said, it worked in the past sometimes but no longer does. When I reboot it simply forgets the order, however, not the actual entries.
2) My UEFI spec is version 2.10 from American Megatrends (MSI motherboard) but it does not include the "bcfg" program. Apparently, this is supposed to be part of the v.2.0 UEFI spec so I am curious why my firmware doesn't include it. Is there a way for me to boot a different EFI shell that will have this feature? For example, could I make an ESP, formatted as FAT16, on a USB device and place a shellx64.efi file on it in the EFI/boot/ directory and it would work? Again, sorry for my ignorance. All my information on EFI comes from your rodsbooks website and the scattered documentation on various wikis (I'm still learning).
3) I have emailed MSI with the hope that they can release the firmware in the way they used to -- a ZIP including the EXE, AMI and docs. The EXE cannot be extracted by unzip or 7zip and I am not sure I would have success with anything else (I remember a utility called cabextract or something similar). The EXE wants to be placed onto a USB key so that it can create its bootable device. I've tried cheating by using a virtual machine but it complains that the motherboard is not supported. Sigh.
4) Next I can try formatting the ESP as FAT16, though it strikes me as odd that this would be the issue if it was working before. I was booting UEFI Arch Linux last week on this board using GRUB2. I'm now using Debian, though Arch does not work, either. The EFI/Microsoft/Boot/bootmgfw.efi gimmick also seems odd to me as I never had an issue with my previous installation (I install Linux first and created all partitions from my LiveCD, so it wasn't Windows that initially set up the "working" installation).
A few side questions:
- What do you use to partition a "fresh" machine? I imagine that you might have an Apple laptop/tower, but do you use a particular distribution of Linux for any other machines? I'm curious if maybe I should use a specific LiveCD that has a different version of GPT fdisk or something.
- Do you have any recommendations of manufacturer boards that seem to work the best? I'm not really in the market myself, but I'm curious if any boards have been particularly finicky.
Thanks!
Correct, the "-O" option to efibootmgr deletes the BootOrder variable but not the actual entries. You wouldn't normally need to use this, though; just use the "-o" option (lowercase rather than uppercase), as in "-o 3,2,7" to boot entry #3 followed by #2 followed by #7. This will change the BootOrder variable. The "-O" option deletes it entirely, so you'd need to use that followed by "-o" to set a new order. If you've changed the BootOrder and it keeps changing back, then that sounds like either a firmware bug or a weird interaction problem between efibootmgr and your specific firmware. This is the sort of thing where using bcfg in the EFI shell might fix the problem.
The EFI shell program is independent of the EFI version on the motherboard. All you need is the shellx64.efi file (or whatever the filename is) for a version 2 shell. See https://wiki.archlinux.org/index.php/Unified_Extensible_Firmware_Interface#UEFI_Shell for links to several shell binaries and instructions on using bcfg. One caveat: A version 2 shell might or might not work with a version 2.10 EFI; that shell is actually part of the EFI 2.3 system. (Yes, the numbering is confusing.)
The FAT16 workaround should not be necessary, but I've run into one system where it was necessary. On that system, the EFI seemed to be unable to read certain files. Unfortunately, these included the kernel (with EFI stub support) I was using, as well as some (but not all) of rEFInd's icons.
Calling the boot loader EFI/Microsoft/Boot/bootmgfw.efi is also totally bogus, but works on some systems that hard-code this filename, along with EFI/BOOT/bootx64.efi, as fallback boot loaders. One of my computers can boot this way, and I've heard reports from others who say they have trouble booting from anything but that filename. (IIRC, that was an HP laptop.) It could be that your system is alternating between working and not working because of some subtle difference between your attempts. EFI is actually comparable in size to the Linux kernel minus its drivers, so it's a pretty huge code base that contains numerous bugs. (EFI's seen much less use than Linux and so is still far from debugged.)
I try to use GPT fdisk for partitioning, but it's often easier to use something that's based on libparted (GParted or a Linux distribution's installer). I don't use Microsoft tools for partitioning unless I'm running tests that require it. In my experience, Microsoft's tools are very flaky. OS X's GUI disk partitioning tool is pretty restrictive, but I sometimes use it when dealing with OS X, since it implements various rules that OS X likes to see implemented on its disks.
As to specific motherboards, I have limited experience. Currently, I've got a recent ASUS board (a P8H77-I), which works well except for an interaction with a KVM switch that has forced me to install a separate video card. (That's not an EFI issue, though.) I've got a Gigabyte GA-78LMT-S2P (rev. 4.0) board with Gigabyte's hybrid EFI implementation, which is dreadful (see the linked-to page for details). I've also got an older Intel board that's so-so -- it's the one that gave me the weird FAT32 problems, and it seems to completely ignore the BootOrder variable.
Thanks for the help.
I now have it booting again. I think what ended up being most helpful was your suggestion to remove ALL the boot options and then create the rEFInd option.
The UEFI Shell 2.0 actually wouldn't run on my 2.10 firmware system, though I suspect maybe something else was the issue (some "assert" error -- but that isn't for this thread).
I'm glad you got it resolved. As you've discovered, there are still some bugs to be worked out with EFI!