I've installed arch on my ThinkPad T420 using LVM on top of LUKS, with separate ext4 boot FAT32 EFI partitions (GPT):
/dev/sda2 on /boot type ext4 (rw,noatime,discard,data=ordered)
/dev/mapper/arch-var on /var type ext4 (rw,noatime,discard,data=ordered)
/dev/mapper/arch-home on /home type ext4 (rw,noatime,discard,data=ordered)
/dev/sda1 on /boot/efi type vfat (rw,noatime,fmask=0022,dmask=0022,codepage=437,iocharset=iso8859-1,shortname=mixed,errors=remount-ro)
# ls -l /boot/efi/EFI/refind
drwxr-xr-x 2 root root 4096 Mar 19 06:17 drivers_x64
drwxr-xr-x 2 root root 4096 Mar 19 06:17 icons
-rwxr-xr-x 1 root root 17452 Mar 19 06:17 refind.conf
-rwxr-xr-x 1 root root 154688 Mar 19 06:17 refind_x64.efi
# efibootmgr -v
Boot0019* rEFInd HD(1,800,100000,7fd611f9-b27b-4299-86da-4977bdf210b4)File(\EFI\refind\refind_x64.efi)
# more /boot/refind_linux.conf
"Boot with defaults" "cryptdevice=/dev/sda3:luks root=/dev/arch/root rootfstype=ext4 ro"
"Boot to terminal" "cryptdevice=/dev/sda3:luks root=/dev/arch/root rootfstype=ext4 ro systemd.unit=multi-user.target"
The problem is, it hangs on the rEFInd boot OS screen when I select to boot from the boot partition - the disk activity on my machine just goes dead, and I have to power cycle it. Oddly, if I use the UEFI shell v1 (v2 panics) on my install USB to start the same rEFInd, it goes on to boot without any trouble at all.
Last edited by iliveinapark (2013-04-03 15:24:42)
I've just noticed that I probably have the same problem as this post. I will continue to monitor both posts and mark as solved if they turn out to have the same solution. Sorry for reposting.
Thanks mate, that seems to describe what's going on with me pretty well, especially the odd behaviour described here regarding being able to boot when the install usb is plugged in - this was the case until I updated my kernel (now at 3.8.3-2).
Have you got any thoughts on why it works just fine if I select the UEFI shell (v1) from rEFInd, use the shell to select rEFInd, and select the entry in the boot partition from there? Does the shell set up something that can be used by the kernel that rEFInd doesn't?
It's possible that the EFI v.1 shell is setting something in the EFI environment that the kernel's EFI stub loader wants to see, but that neither rEFInd nor the v.2 shell is setting. That's rather vague, I know, but it's the only thing that occurs to me that's consistent with the evidence I've seen to date.
Yeah, that's what I thought too, though I certainly don't know enough of the internals to hazard a guess as to what it is... I should point out, though that the v2 shell doesn't have a problem with booting the kernel (or rEFInd for that matter) on my box, it just dies as soon as the .efi application tries to boot. I get the error (ugh, typing):
ASSERT_EFI_ERROR (Status = Device Error)
ASSERT c:\dev\edk2tip\Build\Shell\RELEASE_VS2005\X64\ShellPkg\Application\Shell\Shell\DEBUG\AutoGen.c(431) : !EFI_ERROR (Status)
No idea what that means (or if you care =P), but figured it might be related in some way.
That error means that something in the AutoGen.c file (which is, as the name implies, automatically generated by the TianoCore build kit) is causing an error. This may be the root of the problem for you. This raises the possibility that it's a bug in the TianoCore library, and that something built in another way may be OK. To test that hypothesis, here's a link to a rEFInd binary built with GNU-EFI rather than with TianoCore:
Note that's a "raw" binary file; you'll need to drop in into place of your regular rEFInd binary, using its icons and whatnot.
Thanks man! I'll give it a try as soon as I get home tonight, however I should point out that the error above was thrown by the EFI Shell v2, on the arch install ISO, not rEFInd. I appreciate the help, and admire the effort you put into supporting rEFInd here on the forums. Got a "buy me a beer" page somewhere? Couldn't find on on rodsbooks.com.
Thanks man! I'll give it a try as soon as I get home tonight, however I should point out that the error above was thrown by the EFI Shell v2, on the arch install ISO, not rEFInd.
Yes, I understand that. It's a bit of a long shot that rEFInd compiled with GNU-EFI will work when a binary compiled with TianoCore fails, but it's worth trying, since that error points to a possible TianoCore bug.
I appreciate the help, and admire the effort you put into supporting rEFInd here on the forums. Got a "buy me a beer" page somewhere? Couldn't find on on rodsbooks.com.
There are donation links at the top of the rEFInd documentation pages:
Thanks in advance for any support you offer -- it does help. (My collection of EFI-based computers isn't free! )
Great news! The rEFInd efi you built for me with the GNU-EFI library seems to work. To the best of my knowledge, I haven't changed anything else since the last reboot, and it booted without any problems, it would seem. I'll post to the other two threads I've been keeping track of, and we'll get some others testing it.
That new binary totally fixed boot for me (T430s).
linux-3.8.3-2 never worked before, but with the new binary it does.
Thanks for the reports. I'll prepare a full GNU-EFI rEFInd package and post back later. This does seem like a strange interaction, but at least it's an important clue about the cause of the problem....
Marked as [solved] since I have a working fix. Thanks to srs5694 for all the help.