rEFInd stuck but works using UEFI Shell v1 (but not v2) [FIXED]

greut · 2013-03-09 15:10:35

Hi,

First ArchLinux install and it gets problematic. I've followed the Beginner's guide and am now in the following situation.

rEFInd get stuck on:

rEFInd - Booting OS

Starting vmlinuz-arch.efi
Using load options 'root=/dev/sda5 ro rootfstype=ext4 add_efi_memmap initrd=\EFI\arch\initramfs-arch.img'

The \EFI\arch\refind_linux.conf contains the following line:

"Boot" "root=/dev/sda5 ro rootfstype=ext4 add_efi_memmap initrd=\EFI\arch\initramfs-arch.img"

Interestingly, when I start it from the UEFI shell (from the arch installation cd) it works with the v1 but not the v2 !?

What did I overlook?

edit: initrt was a typo… sorry.

Last edited by greut (2013-03-27 18:10:53)

srs5694 · 2013-03-09 17:16:01

Exactly what options do you pass to launch the kernel with both of those shells? It could be there's a typo somewhere along the line. Certainly that's the case in what you've reported; in your reporting of what rEFInd displays, you include "initrd=\EFI\arch\initramfs-arch.img", but your copy of refind_linux.conf includes "initrt=\EFI\arch\initramfs-arch.img" instead -- note the difference in the name of "initrd" vs. "initrt". If your copied refind_linux.conf is accurate, that might be the source of the problem, since the parameter must be "initrd", not "initrt".

greut · 2013-03-10 12:20:17

My description was patchy… let's fix that.

/boot/efi/EFI/
 + arch
  - initramfs-arch-fallback.img
  - initramfs-arch.img
  - refind_linux.conf
  - vmlinuz-arch.efi
 + Boot
  - bootx64.efi
  - icons/
  - LenovoBT.EFI
  - License.txt
  - ReadMe.txt
  - refind.conf
 + Lenovo
 + Microsoft
 + refind
  - icons/
  - refind.conf
  - refind_x64.efi

refind_linux.conf

"Boot to normal" "root=/dev/sda5 ro rootfstype=ext4 add_efi_memmap initrd=\EFI\arch\initramfs-arch.img"
"Boot to X" "root=PARTUUID=b5…a9 ro rootfstype=ext4 add_efi_memmap systemd.log_level=debug systemd.unit=graphical.target"
"Boot to terminal" "root=PARTUUID=b5...a9 ro rootfstype=ext4 add_efi_memmap systemd.log_level=debug systemd.unit=multi-user.target"

Kernel version is 3.7.10-1.

Booting using archiso EFI shell v1

> fs0:
fs0:\> cd \EFI\arch
fs0:\EFI\arch> vmlinuz-arch.efi root=/dev/sda5 ro rootfstype=ext4 add_efi_memmap initrd=\EFI\arch\initramfs-arch.img
Success!!

Booting using archiso EFI shell v2

> fs1:
fs1:\> cd \EFI\arch
fs1:\EFI\arch> vmlinuz-arch.efi root=/dev/sda5 ro rootfstype=ext4 add_efi_memmap initrd=\EFI\arch\initramfs-arch.img
Stuck :-/

And sadly, rEFInd booting behaves like v2 for some reason !?

srs5694 · 2013-03-10 17:45:05

First, try adding a space to the end of the options when you launch via EFI shell v2 and see if that helps. (You can do the same with rEFInd by hitting Insert or F2 twice rather than Enter to launch; you'll then have a simple line editor you can use to edit your options.) If this helps, report back here.

Second, try simplifying your command line. The "rootfstype=ext4 add_efi_memmap" options are probably unnecessary, so removing them (at least for testing) is desirable.

cfr · 2013-03-10 23:06:11

Since I've never got any EFI shell working on my system, I'm not familiar with their ways so the answer to the following question could very easily be "yes". Is it intended/normal that the file system in v1 is numbered 0 while than in v2 is numbered 1? That is, is this due to a labelling change in v2?

Can you boot to the terminal? (I notice that entry specifies the location of root differently.)

greut · 2013-03-18 21:18:59

srs5694 wrote:

First, try adding a space to the end of the options when you launch via EFI shell v2 and see if that helps. (You can do the same with rEFInd by hitting Insert or F2 twice rather than Enter to launch; you'll then have a simple line editor you can use to edit your options.) If this helps, report back here.

Thanks for the F2 trick, it's very useful. It doesn't help though, sadly.

srs5694 wrote:

Second, try simplifying your command line. The "rootfstype=ext4 add_efi_memmap" options are probably unnecessary, so removing them (at least for testing) is desirable.

Yep, I can boot using only:

vmlinuz-arch.efi root=/dev/sda5 ro initrd=\EFI\arch\initramfs-arch.img

But still, it works with the UEFI Shell v1 from the liveUSB but not using the shell v2 or via rEFInd directly.

iliveinapark · 2013-03-18 21:37:30

Seems we have a very similar problem, mate. I did see your post before posting mine, but didn't realise how similar they were for some reason. I'll let you know if I find a solution that might work for you.

s1ln7m4s7r · 2013-03-18 22:08:39

I will just post an idea!
*******************************************************
If you are only able to boot your system with uefi-shell (v1), you could follow this topic.

https://wiki.archlinux.org/index.php/Un … UEFI_Shell

Download uefi-shell v1 file and place it under "/boot/efi/shellx64.efi" to see if it loads the uefi-shell. Then you could create a "/boot/efi/startup.nsh" file with:

fs0:
cd \EFI\arch
vmlinuz-arch.efi root=/dev/sda5 ro rootfstype=ext4 add_efi_memmap initrd=\EFI\arch\initramfs-arch.img

It should load your system automatically.

NOTE: Remember that i actually don't know if your UEFI will automatically load the shell, because i never tested it. But you lose nothing to try.

Last edited by s1ln7m4s7r (2013-03-18 22:09:23)

srs5694 · 2013-03-18 22:32:30

greut wrote:

srs5694 wrote:
Second, try simplifying your command line. The "rootfstype=ext4 add_efi_memmap" options are probably unnecessary, so removing them (at least for testing) is desirable.
Yep, I can boot using only:
vmlinuz-arch.efi root=/dev/sda5 ro initrd=\EFI\arch\initramfs-arch.img
But still, it works with the UEFI Shell v1 from the liveUSB but not using the shell v2 or via rEFInd directly.

Is there any particular reason you need those options? If not, just leave them out and call it fixed. If you care to do more investigation, though, I'd be interested in knowing which of those two options is causing problems -- or perhaps if only the combination of both of them is causing problems. If either alone works but not both, then I'm inclined to suspect there's a problem with the length of the options line, although that seems odd, since I'm pretty sure I've tested with long options lines in the past with no sign of trouble.

I also can't help but wonder if this might somehow be related to the problem being discussed in this thread, which also has a bug report here. That seems to be a problem with specific kernels, but it's conceivable that there's an interaction between kernels and some other unknown factor.

FWIW, I just did a quick scan of the most relevant section of the rEFInd code and I didn't spot anything suspicious about how it's handling those strings. In fact, it's using allocated memory rather than fixed character arrays, so a hard limit caused by a string of length x seems to be unlikely as a cause unless it were in the kernel's EFI stub loader -- and then you wouldn't see the difference based on the boot manager type (EFI shell v.1 vs. EFI shell v.2 vs. rEFInd).

iliveinapark · 2013-03-20 12:04:32

Great news, everyone!

Rod was looking into my error with booting EFI shell V2, and surmised that the bug may lie in a library he uses to compile rEFInd (as far as I understand it). He provided me with a different rEFInd binary, and my machine boots with it. Details over in my thread on the install subforum.

maxmcmax · 2013-03-22 21:58:12

Unfortunately, it didn't work out for me. I built the refind with GNU-EFI, but the reason was the Kernel stub :-(

I downgraded to 3.7.4-1 and now it works again. Tomorrow I'll try to upgrade step-by-step again...at least I know that 3.7.9-2 and above do not work.

My system is a little tricky, though, being an old 2007 Macbook. ;-)

Last edited by maxmcmax (2013-03-22 21:58:45)

mrunion · 2013-03-22 22:00:56

Just upgraded to Kernel 3.8.4-1 via pacman update. Now everything boots fine via regular rEFInd (0.6.7-1). Go figure? I will keep an eye on it! This is confusing!

maxmcmax · 2013-03-23 10:42:04

The upgrade worked on my UEFI Atom computer, but not on the 2007 Macbook :-( Maybe it has something to do with the old V1 EFI on the Mac and the newer V2 EFI on the Atom...

M.

maxmcmax · 2013-03-24 08:14:43

OK, the following combination works on Macbook now

core/linux 3.7.9-2
extra/refind-efi 0.6.4-1

Alternatively you can build refind with GNU-EFI support, which works too. I had to re-bless refind after downgrading, though.

The currently rolled out versions

linux 3.8.4-1
refind-efi 0.6.8-1

happen to boot a little bit and hang after "can't load kernel modules" and "can't mount hfsplus partition". I got once the chance to enter the root password in emergency mode, all other attempts to boot got a blinking cursor to enter the root pw and no system reaction. I added hfsplus to the mkiniticpio MODULES line, but no success here. :-(

Maybe I start filing tickets now.

Last edited by maxmcmax (2013-03-24 08:36:54)

greut · 2013-03-27 18:12:19

Using linux 3.8.4-1 fixed somehow fixed it. I've also put the Shell in a handful place, so I can reach it directly. Thanks you all for your help.

Arch Linux

#1 2013-03-09 15:10:35

rEFInd stuck but works using UEFI Shell v1 (but not v2) [FIXED]

#2 2013-03-09 17:16:01

Re: rEFInd stuck but works using UEFI Shell v1 (but not v2) [FIXED]

#3 2013-03-10 12:20:17

Re: rEFInd stuck but works using UEFI Shell v1 (but not v2) [FIXED]

#4 2013-03-10 17:45:05

Re: rEFInd stuck but works using UEFI Shell v1 (but not v2) [FIXED]

#5 2013-03-10 23:06:11

Re: rEFInd stuck but works using UEFI Shell v1 (but not v2) [FIXED]

#6 2013-03-18 21:18:59

Re: rEFInd stuck but works using UEFI Shell v1 (but not v2) [FIXED]

#7 2013-03-18 21:37:30

Re: rEFInd stuck but works using UEFI Shell v1 (but not v2) [FIXED]

#8 2013-03-18 22:08:39

Re: rEFInd stuck but works using UEFI Shell v1 (but not v2) [FIXED]

#9 2013-03-18 22:32:30

Re: rEFInd stuck but works using UEFI Shell v1 (but not v2) [FIXED]

#10 2013-03-20 12:04:32

Re: rEFInd stuck but works using UEFI Shell v1 (but not v2) [FIXED]

#11 2013-03-22 21:58:12

Re: rEFInd stuck but works using UEFI Shell v1 (but not v2) [FIXED]

#12 2013-03-22 22:00:56

Re: rEFInd stuck but works using UEFI Shell v1 (but not v2) [FIXED]

#13 2013-03-23 10:42:04

Re: rEFInd stuck but works using UEFI Shell v1 (but not v2) [FIXED]

#14 2013-03-24 08:14:43

Re: rEFInd stuck but works using UEFI Shell v1 (but not v2) [FIXED]

#15 2013-03-27 18:12:19

Re: rEFInd stuck but works using UEFI Shell v1 (but not v2) [FIXED]

Board footer