Latest version 0.7.0 is not bootable on some machines
An EFI boot manager utility
Status: Beta
Brought to you by:
srs5694
Menu
▾
▴
It simply loads to a blank screen (the application never starts so I can't test kernels -- too bad, I wanted to try out the BTRFS driver!)
The machine I am using is an MSI motherboard and I can give the UEFI version specs or anything else needed. I say "some machines" because it probably works for some people. I've tried the flashdrive version and tiano and GNU builds on ESP.
What was the last version that did work for you? To pin this down, I need to know when the problem began for you. I may also need for you to run some test/debugging versions that display messages as they run and report back the results.
Also, please try the rEFInd binary from 0.7.0 without its drivers, and try the 0.7.0 drivers (or at least the ones you used with 0.7.0) with the last version of rEFInd that did work. This will reveal whether it's the drivers or rEFInd itself that's crashing.
Last edit: Roderick W. Smith 2013-06-29
version 0.6.12 (Tiano build) works OK.
I saw on Arch forums that someone had said that the drivers might be the cause. I'll admit my tactic was lazy here -- I only renamed the driver directory and that did not work, but I can try removing it entirely.
Thanks for the quick response.
Last edit: badhat 2013-06-29
I just checked the Arch forums, and I couldn't find any thread in which rEFInd 0.7.0 problems are being discussed. Could you please post the URL? Thanks. Also, I've been corresponding with the maintainer of one of the two Arch rEFInd packages, and it seems there's a problem that's been introduced with the development version of Tianocore that's not present in the stable version I'm using. This problem causes rEFInd to hang when starting. It's not clear to me what the source of the problem is, but if you're using an Arch package of 0.7.0, don't. Use one of my binary builds instead.
If you find that the rEFInd binary is the cause, please try this test/debug version:
http://www.rodsbooks.com/refind_0.7.0.1_x64.efi
That's just a bare
.efifile; copy and rename it so you can launch it. It should display a series of messages about files that it's testing for validity, and it will periodically ask you to hit Enter to continue. (This is one of only two changes to the rEFInd binary from 0.6.12 to 0.7.0, and it's the one that's more complex and therefore more likely to cause problems.) Please post back with the last couple of lines of output that you see before it hangs (if it does).The debug rEFInd seems to work just fine. All it tells me is that each of my efi applications are valid.
One caveat, the version of that file is 0.7.0.1 while the version I am having trouble with is 0.7.0 (http://sourceforge.net/projects/refind/files/0.7.0/refind-flashdrive-0.7.0.zip/download).
Is there any change in that last minor version number?
I checked again to be sure and the bootable flashdrive version doesn't work on this machine but it will work on others (I also tried the compiled binary, both GNU and Tiano, as stated before).
The version 0.7.0.1 that you tried changes nothing except to add the debugging statements.
Perhaps there's something odd about the way the program was being launched -- for instance, if you installed the program manually and there was a typo in your
efibootmgrcommand, which you corrected when you tried the debug version. OTOH, that wouldn't explain why the USB flash drive version failed.Have you tested without the EFI drivers? It's conceivable that the drivers are (or one of them is) causing the problem.
Hrm... the method that I used to test this debug binary was to copy it over to the path of the working binary, so no new entry was created with efibootmgr. I was able to successfully launch the debug binary in this manner.
You're right, it's strange that this version does not work if all that has changed are the debug statements, but then what gives with the USB? Mind you, the USB drive works on a laptop, so it shouldn't be the issue.
The drivers sound more and more like that might be it. Rather than renaming the directory (and keeping it on the ESP) I can just remove them entirely. My firmware should be able to read FAT without any help anyways, no? I'll check this evening and if I find which driver is problematic I can update here (though it seems like it's already been reported in other places).
Badhat (or anybody else with this problem), I'm still waiting on definitive word about where this bug exists -- in the drivers or in the main rEFInd binary. (If the problem is with the drivers, knowing which driver(s) are at fault is also vital information.) I can't even begin to debug the program unless I know which program to debug! I haven't been able to replicate this problem locally, and in such cases I really do need the help of somebody who's actually experiencing the problem in order to fix it.
The offending driver for me is the new btrfs_x64.efi.
Removing this file allows me to boot without issue.
As a side note, it appears that renaming the driver directory does not change whether rEFInd can detect the drivers so long as they are present on the ESP(I suppose it searches for all *.efi files?).
Could you please try the following Btrfs driver:
http://www.rodsbooks.com/btrfs_x64.efi
This includes an ugly hack that might work around the problem. I'll look for a better long-term solution too, of course, but if this works I may do a 0.7.1 release just to get it out there....
Oh, and renaming the drivers directory should keep the drivers from being loaded, so long as the name is neither
driversnordrivers_x64. OTOH, I've run into some weird FAT issues on some EFI implementations. It's conceivable that renaming a directory would work under Linux but that the directory would still appear under the old name as far as EFI is concerned. If so, that's clearly a bug, but it wouldn't be the weirdest bug I've heard of in EFI.I'm now doubtful that the version of the Btrfs driver I just posted will be helpful. I've managed to reproduce the problem (or at least a system hang) on one of my VirtualBox installations, but it happens with both versions of the driver. Also, it happens only when a CD is inserted in the (virtual) CD drive -- and even then, only with certain CDs. I'm pretty sure it's the ISO-9660 or Rock Ridge driver in the VirtualBox EFI that's actually crashing, although this is clearly interacting with the Btrfs driver in some way -- probably the Btrfs driver is messing up some shared data structure. In any event, I'd like to know if your problem occurs when a CD-R is not inserted in your drive. If the problem occurs without a CD-R, what other filesystems do you have on your computer, and do you have other EFI drivers for any of them?
I think I've fixed the bug. I've uploaded the fixed version to:
http://www.rodsbooks.com/btrfs_x64-fixed.efi
The source code is in the rEFInd git repository. I'd appreciate it if you could check this out. If this is indeed fixed I'll release it as version 0.7.1. Thanks!
Thanks, Roderick. Bear with me (I know I have been slow to respond).
Tonight I can test the new version. As it happens I have no CDROM device attached to my computer. On occasion I do have a bootable USB drive, though the hang seems independent of that. A couple peripherals that might be affecting the problem (that I can remove to test) are:
1) Kingston FCR-HS3 15-in-1 USB 3.0 Media Reader
2) Cavalry EN-CAHDD2BU3C-ZB 2.5in and 3.5in Standalone SATA/USB 3.0 Dual-Bay Dock
I have several drives using btrfs, though the only disk with an ESP the partitions:
And the filesystems:
Apologies for the formatting. The "code" type seemed far too big so I went with a text block. Anyway, I'm only booting from the FAT32 partition and I don't think my firmware needs a driver at all for that. There is just the Linux efistub and a Microsoft bootloader there at present (along with rEFInd).
Be aware that I've released a 0.7.1 version with these fixes, so if you could please test with that, I'd appreciate it. Thanks!
Version 0.7.1 works for me. Not only that, the btrfs.efi driver picked up my /boot on my root partition (btrfs) which almost eliminates the need for a FAT32 ESP.
Thanks for solving this :)