Can't boot using EFISTUB

Hika · 2012-12-23 19:27:18

Hello,

I am trying to install arch on my recent laptop (lenovo thinkpad) in UEFI. I already made an aproximatively successful install of arch few weeks ago using grub, and I believe it should work, but I just prefer refind wich seems clearer to me (I mean I feel like I know what part of the computer Im changing, while grub-install is just too magic for me, especially when I end up still having a part of the grub on a completly formated hard disk... anyway).

When I try to boot arch from rEFInd, the system hangs on "using load options *load options i chosed*". It seems to freeze and all I can do is press power button to reboot laptop.
I checked files in my efi partition and i'm sure everything is fine. I have a refind_linux.conf file in my arch folder, created with what I found in the beginner's guide

"Boot to 5"          "root=/dev/sda5 ro rootfstype=ext4 systemd.unit=graphical.target"
"Boot to console"    "root=/dev/sda5 ro rootfstype=ext4 systemd.unit=multi-user.target"

I also tryed to use label or partuuid in it (root=PARTUUID=XXXXXX) and it didnt solve the problem.

I created a custom entry with the refind.conf file (in EFI/refind/ folder), adding something like :

menuentry "Arch" {
        icon   \EFI\BOOT\icons\os_arch.icns
	loader \EFI\arch\vmlinuz-arch.efi
	initrd  \EFI\arch\initramfs-arch.img
	options "ro root=/dev/sda3"
}

One interesting thing I noticed when doing this is that when I made mistake with paths for kernel or ram, refind would tell me so and wouldnt crash. The hang really happens upon loading those files.

I tryed to boot arch from the efi shell that I could access from the usb drive I used for installation, and had the same crash problem in the console.
That made me think that something was really wrong with my vmlinuz-linux file or my initramfs, I tryed reinstalling both with mkinitcpio and pacman -S linux, still got stuck. Of course after the updates I would recopy them in /EFI/arch/ folder with the correct names according to the wiki.

I was able to partly boot to arch from refind by replacing my vmlinuz with the one that was given with the arch iso (downloaded from torrent on the official site), but everything wasn't still right and I found that solution messy anyway and didnt want to search too much on that path.

So that's it, i hope it is clear, my english is far from perfect and I apologyze for that. And hi everyone by the way, i'm new to arch, still not sure if i'm going to use that distribution. I'm usually not the linux type but I have to say i'm much more excited about this one than the others I used (ubuntu and stuff like that). At least, when i encounter a problem (and for some reason, I alwails encounter loads of problems on linux), I learn stuff.

Thanks

srs5694 · 2012-12-23 19:40:42

First, it's important to know where your kernels are. From the refind.conf manual boot stanza you've posted, it looks as if you've copied your kernels and initrd files to the EFI/arch directory on your ESP. If this is incorrect, then that's a problem with at least the manual boot stanza.

Second, for the auto-detection code (with refind_linux.conf), rEFInd matches the first initrd file it finds to your kernel. Arch, though, provides two initrd files for your default kernel, so rEFInd might be launching either of those initrd files. If you want to use auto-detection, it's best to include separate options lines, each of which references a specific initrd file. With the last couple versions of rEFInd, those references will override the auto-detection. I doubt if this is really your problem, but it could be at least part of it, and it's something you should keep in mind in the future in any event.

Third, what kernel version are you using? Early versions of the EFI stub loader didn't display error messages when they couldn't find their initrd files. Newer versions do. (I don't recall where the cutoff was, though -- probably with 3.5.0 or perhaps 3.6.0.) Thus, if you're using an old version, it could be that the kernel can't find the referenced initrd file for some reason, and so is silently hanging. If you're using a more recent kernel, this is less likely, since the kernel should display an error message to the effect that it couldn't load the initrd file.

Beyond that, I'm not sure. Maybe you've encountered an obscure bug in the EFI stub loader, or perhaps your kernel is incompatible with your hardware in some basic way. A kernel version upgrade might fix it, or you could try installing ELILO and use that -- ELILO will at least bypass the EFI stub loader, in case it's the cause of your problem. (GRUB 2 might also work, but ELILO is much easier to configure manually.)

Hika · 2012-12-23 20:02:50

Thanks for your very fast answer.

srs5694 wrote:

First, it's important to know where your kernels are. From the refind.conf manual boot stanza you've posted, it looks as if you've copied your kernels and initrd files to the EFI/arch directory on your ESP. If this is incorrect, then that's a problem with at least the manual boot stanza.

The code I posted is right. I wanted to say that first I right wront paths (lets say with loader set to \vmlinuz-linux), and refind would tell me i'm wrong. The paths I wrote are correct, are what is advised in the arch wiki, and are causing the crash.

srs5694 wrote:

Second, for the auto-detection code (with refind_linux.conf), rEFInd matches the first initrd file it finds to your kernel. Arch, though, provides two initrd files for your default kernel, so rEFInd might be launching either of those initrd files. If you want to use auto-detection, it's best to include separate options lines, each of which references a specific initrd file. With the last couple versions of rEFInd, those references will override the auto-detection. I doubt if this is really your problem, but it could be at least part of it, and it's something you should keep in mind in the future in any event.

I am not sure I understand this one. You mean I should add an "initrd=\EFI\arch\initramfs-arch.img" to each of my options ? I thought about doing so but I read somewhere someone saying that that kind of feature (specifying initrd for auto-detection entries) wasn't implemented yet. I will do this in the future anyway.
I know that the autodetection is working correctly for this, as the message "loading options..." that is displayed just before the crash shows an initrd that is correct (as you said, sometimes it loads the fallback ram one, sometime the normal one). So I guess just as you do that the problem doesn't come from this.

By the way, how do I access the options I added in refind_linux ? I couldnt find it, I tryed to press inser or + as I read somewhere, got redirected to an empty menu. I first thought I made a mistake with the refind_linux file, but the options I add in it are taken in account for default loading (as I said i can see the loading options just before the crash so i could check).

srs5694 wrote:

Third, what kernel version are you using? Early versions of the EFI stub loader didn't display error messages when they couldn't find their initrd files. Newer versions do. (I don't recall where the cutoff was, though -- probably with 3.5.0 or perhaps 3.6.0.) Thus, if you're using an old version, it could be that the kernel can't find the referenced initrd file for some reason, and so is silently hanging. If you're using a more recent kernel, this is less likely, since the kernel should display an error message to the effect that it couldn't load the initrd file.

As I said I tryed to reinstall the kernel , so I guess I must have the last version. I just typed pacma -Q, I got the package linux 3.6.10-1 installed.

Beyond that, I'm not sure. Maybe you've encountered an obscure bug in the EFI stub loader, or perhaps your kernel is incompatible with your hardware in some basic way. A kernel version upgrade might fix it, or you could try installing ELILO and use that -- ELILO will at least bypass the EFI stub loader, in case it's the cause of your problem. (GRUB 2 might also work, but ELILO is much easier to configure manually.)

Well, grub 2 used to work with a previous install I made of arch. The only changed I made since that time is a bios update, could it cause that kind of problem ?

I might also try a proper reinstall of rfind using the guide that is on the offical refind site instead of the arch one.
If I am right, a proper uninstall of refind would be to remove the package using pacman, revert all the modifications I made in the EFI partition, and remove the boot entry in bios using efibootmgr. (that's partly a question)

Last edited by Hika (2012-12-23 20:11:56)

cfr · 2012-12-23 20:38:19

I added the following to /boot/efi/EFI/arch_refind/refind.conf (if you are following the wiki, use /boot/efi/EFI/refind/refind.conf):

menuentry "Arch Linux" {
        loader EFI/arch/vmlinuz-arch.efi
        initrd EFI/arch/initramfs-arch.img
        icon EFI/arch_refind/icons/os_arch.icns
        options "root=<dev path for root> ro rootfstype=<fs type> cryptdevice=<specify if root is encrypted> resume=<resume device if applicable> <other options> add_efi_memmap"
        submenuentry "CLI" {
                add_options "systemd.unit=multi-user.target"
        }
        submenuentry "Fallback" {
                initrd EFI/arch/initramfs-arch-fallback.img
        }
        submenuentry "Fallback CLI" {
                initrd EFI/arch/initramfs-arch-fallback.img
                add_options "systemd.unit=multi-user.target"
        }
        submenuentry "Rescue" {
                initrd EFI/arch/initramfs-arch-fallback.img
                options "root=<dev path for root> ro rootfstype=<fs type> cryptdevice=<specify if root is encrypted> systemd.unit=rescue.target"
        }
}

menuentry "Arch Linux LTS" {
        loader EFI/arch/vmlinuz-arch-lts.efi
        initrd EFI/arch/initramfs-arch-lts.img
        icon EFI/arch_refind/icons/os_arch.icns
        options "root=<dev path for root> ro rootfstype=<fs type> cryptdevice=<specify if root is encrypted> resume=<resume device if applicable> <other options> add_efi_memmap"
        submenuentry "CLI" {
                add_options "systemd.unit=multi-user.target"
        }
        submenuentry "Fallback" {
                initrd EFI/arch/initramfs-arch-lts-fallback.img
        }
        submenuentry "Fallback CLI" {
                initrd EFI/arch/initramfs-arch-lts-fallback.img
                add_options "systemd.unit=multi-user.target"
        }
        submenuentry "Rescue" {
                initrd EFI/arch/initramfs-arch-lts-fallback.img
                options "root=<dev path for root> ro rootfstype=<fs type> cryptdevice=<specify if root is encrypted> systemd.unit=rescue.target"
        }
}

I also tried to configure refind_linux.conf under /boot/efi/EFI/arch/ but I'm not actually using any of that configuration so it is entirely untested whereas the above is only mostly untested. (But I do get the options in the sub-menu at boot and I can boot at least the default kernel etc. - haven't tried the other entries yet.)

If you do it this way, you will probably also want to add:

dont_scan_dirs EFI/boot,EFI/arch

to refind.conf to stop refind adding the auto-scanned entries in addition to the manually configured ones.

Note that I've only just set this stuff up so this may be the blind failing to lead the blind. However, I did get sub-menus and I could boot.

I'm not sure whether add_efi_memmap should be added in the options for the rescue.target case or not.

srs5694 · 2012-12-23 20:43:11

Hika wrote:

srs5694 wrote:
Second, for the auto-detection code (with refind_linux.conf), rEFInd matches the first initrd file it finds to your kernel. Arch, though, provides two initrd files for your default kernel, so rEFInd might be launching either of those initrd files. If you want to use auto-detection, it's best to include separate options lines, each of which references a specific initrd file. With the last couple versions of rEFInd, those references will override the auto-detection. I doubt if this is really your problem, but it could be at least part of it, and it's something you should keep in mind in the future in any event.
I am not sure I understand this one. You mean I should add an "initrd=\EFI\arch\initramfs-arch.img" to each of my options ?

Yes -- but see below. Also, you'd probably want to create at least one entry that references the fallback initrd rather than the default one.

I thought about doing so but I read somewhere someone saying that that kind of feature (specifying initrd for auto-detection entries) wasn't implemented yet. I will do this in the future anyway.

It's a very recent feature. I'm not sure if it's implemented in the version of rEFInd you'd get via pacman, but it's definitely present in the latest version of rEFInd available from its own downloads page.

By the way, how do I access the options I added in refind_linux ? I couldnt find it, I tryed to press inser or + as I read somewhere, got redirected to an empty menu. I first thought I made a mistake with the refind_linux file, but the options I add in it are taken in account for default loading (as I said i can see the loading options just before the crash so i could check).

After you highlight your main Arch option, pressing Insert, F2, or + should bring up a menu of the sub-options specified in refind_linux.conf or in the manual boot stanza you created. Highlight one of these and press Insert, F2, or + again and you should see the options editor screen with the current options. If you see the editor but the options it shows are blank, or show only the initrd= option, then that suggests that you've not placed refind_linux.conf correctly; the file should be in the same directory as the kernels to which it applies. If you don't get an editor at all, then that suggests you're using an old version of rEFInd; the options editor was added with version 0.4.7.

srs5694 wrote:
Third, what kernel version are you using? Early versions of the EFI stub loader didn't display error messages when they couldn't find their initrd files. Newer versions do. (I don't recall where the cutoff was, though -- probably with 3.5.0 or perhaps 3.6.0.) Thus, if you're using an old version, it could be that the kernel can't find the referenced initrd file for some reason, and so is silently hanging. If you're using a more recent kernel, this is less likely, since the kernel should display an error message to the effect that it couldn't load the initrd file.
As I said I tryed to reinstall the kernel , so I guess I must have the last version. I just typed pacma -Q, I got the package linux 3.6.10-1 installed.

OK, so if you try to launch that and the system hangs without displaying an error message, that suggests that the problem isn't simply that the kernel can't find its initrd file.

Beyond that, I'm not sure. Maybe you've encountered an obscure bug in the EFI stub loader, or perhaps your kernel is incompatible with your hardware in some basic way. A kernel version upgrade might fix it, or you could try installing ELILO and use that -- ELILO will at least bypass the EFI stub loader, in case it's the cause of your problem. (GRUB 2 might also work, but ELILO is much easier to configure manually.)
Well, grub 2 used to work with a previous install I made of arch. The only changed I made since that time is a bios update, could it cause that kind of problem ?

Perhaps. UEFI firmware is still immature. It's also big -- the core of EFI is about the same size as the core of the Linux kernel (without its drivers), and it's not nearly as well tested. That's a breeding ground for bugs, and I've seen some weird ones.

That said, you've switched from GRUB 2 to the EFI stub loader at the same time you upgraded your firmware. Thus, it's impossible to say which change has caused the problem. My hunch is it's the switch from GRUB 2 to to the EFI stub loader, but it could be that the latter is failing because of a problem with your firmware (new or old version might not matter).

I might also try a proper reinstall of rfind using the guide that is on the offical refind site instead of the arch one.
If I am right, a proper uninstall of refind would be to remove the package using pacman, revert all the modifications I made in the EFI partition, and remove the boot entry in bios using efibootmgr. (that's partly a question)

Yes, that would uninstall rEFInd. The latest version (0.6.1) has an install.sh script that should do the job right in most cases, although you might need to use a parameter or two on some systems. If you're using an emergency boot disc, in particular, note the new --root option, which you use to point to the root of your regular installation. (You should mount your /boot and/or ESP at appropriate places within that tree, too.) Also, be aware that rEFInd's defaults are built with Fedora, Ubuntu, SUSE, and similar distributions in mind. Arch's naming and handling of kernels is unusual, which is why you might need to explicitly specify your initrd in refind_linux.conf or create manual boot stanzas in refind.conf for Arch but not for most other distributions.

srs5694 · 2012-12-23 21:01:04

cfr wrote:

I added the following to /boot/efi/EFI/arch_refind/refind.conf (if you are following the wiki, use /boot/efi/EFI/refind/refind.conf):
...
Note that I've only just set this stuff up so this may be the blind failing to lead the blind. However, I did get sub-menus and I could boot.

That looks reasonable on a cursory examination, although it should be emphasized that you've put variables between angle brackets ("<like this>"), and those need to be customized for each system, not entered literally.

One more comment: rEFInd has been adding features that make it practical on more and more systems to boot a Linux kernel from Linux's /boot directory rather than from the ESP. Currently, this is possible if the /boot directory resides on a FAT, HFS+, ext2fs, ext3fs, ext4fs, or ReiserFS partition, but not if it's on XFS, JFS, or Btrfs, or if it's in a RAID or LVM setup. If you're in one of the supported configurations, something like this could replace your first few lines:

menuentry "Arch Linux" {
        icon EFI/arch_refind/icons/os_arch.icns
        volume archroot
        loader /boot/vmlinuz-arch.efi
        initrd /boot/initramfs-arch.img

This loads the kernel and initrd from the /boot directory on the filesystem with the filesystem label "archroot". You'd need to change the volume label for your system, of course, and in fact you might need to set a volume label for your root partition (mkfs doesn't create one by default). Alternatively, you could use something like "volume 1:" to specify filesystem #1 (numbered from 0), but that numbering could change if you repartition or add or delete EFI filesystem drivers. Note that I've moved the "icon" line earlier, to precede the "volume" line; otherwise, you'll need to copy the relevant icon to the Linux root filesystem. If you've got a separate /boot partition, you'd need to adjust both the "volume" line and the references to the files appropriately (removing "/boot" from the paths). Unless the filesystem in question is FAT (or HFS+ on Macs), you'll need to have the appropriate filesystem driver in the drivers or drivers_x64 subdirectory of the rEFInd directory on the ESP.

All of this has the advantage of obviating the need to copy your kernel to the ESP after every kernel update. I realize that there are instructions in the Arch wiki for automating this, so in the end either configuration should require little or no maintenance. IMHO, though, reading the kernel directly from Linux's /boot directory is a little more elegant. It's also robust against failures of the automation script (say, if your ESP fills up). OTOH, reading directly from /boot means you're dependent on an EFI filesystem driver (unless you've got a separate FAT /boot partition), so if the driver file gets lost, you won't be able to boot until you restore it.

Hika · 2012-12-23 21:25:06

For the sub-options things on refind, all I can see when pressing f2, + or inser, is a text "Boot options for \EFI\arch\vmlinuz-arch.efi on BOOT" (the name of my efi partition).
Below is a logo of arch, then nothing (the top logo of refind and the grey background image remain of course), using keyboard arrows doesnt change display in anyway.

refind says I am using have version 0.5 (in the about menu).

I might try to make a fresh install of refind following the tutorial on the refind site if I can't fix that later. But for now as I cant even boot from the efi shell I guess it's not the prioriy.

cfr > thanks for you're help, though I don't believe that my problem comes from my configuration files, but I guess that what srs just explained to you helped us both. I will keep my vmlinuz and ram on /boot for future installs, saves a lot of time.

For know I guess I will just try to downgrade my bios and see how things go. Thanks again.

srs5694 · 2012-12-23 23:27:36

Hika wrote:

For the sub-options things on refind, all I can see when pressing f2, + or inser, is a text "Boot options for \EFI\arch\vmlinuz-arch.efi on BOOT" (the name of my efi partition).
Below is a logo of arch, then nothing (the top logo of refind and the grey background image remain of course), using keyboard arrows doesnt change display in anyway.
...
cfr > thanks for you're help, though I don't believe that my problem comes from my configuration files, but I guess that what srs just explained to you helped us both. I will keep my vmlinuz and ram on /boot for future installs, saves a lot of time.

The first part of your post means that your conclusion in response to cfr is incorrect. If you're not seeing sub-options on the sub-options menu, then your refind_linux.conf file is not being read -- at least, not if it's the one shown earlier in this thread. That file should produce two options on the sub-options menu, one called "Boot to 5" (or "Boot using default options" on earlier versions of rEFInd) and the other called "Boot to console." Here's what it looks like on one of my systems:

As I say, the refind_linux.conf file must exist in the same directory as the kernel(s) to which it applies. (I've had some users mistakenly place it in rEFInd's main directory, but that's wrong.) It could also be you've got a typo in its filename, so check for that.

P.S.: Rather than describe something like this, try grabbing a screen shot or post a listing. In rEFInd, F10 takes a screen shot (saved as screenshot.bmp in the root of the ESP). The Linux "ls" command can show you what files are present, and posting their output can be valuable. Typing "ls -R /boot" and posting the output in code tags will show us what files are on your ESP.

Last edited by srs5694 (2012-12-23 23:29:50)

cfr · 2012-12-23 23:31:53

I plan to switch to loading the kernel etc. from /boot when the ext4 driver gets into the Arch refind-efi package. I know I could use the upstream version and have that now but then I'd have mess to clear up later or I'd have to turn it into a package and, well, I'd already set this up and it works and I'm not impatient (about this).

Hika · 2012-12-24 01:21:33

srs5694 wrote:

As I say, the refind_linux.conf file must exist in the same directory as the kernel(s) to which it applies. (I've had some users mistakenly place it in rEFInd's main directory, but that's wrong.) It could also be you've got a typo in its filename, so check for that.

I saw many mistakes on the forum about this so it is one of the first thing I checked. refind_linux.conf is with the .efi and the ram files, and is what I have written above. As i said the loading options I put in it are taken in acount (before crashing) so I can tell it is at least partly read.

I should say "was", as it seems my laptop just died after I downgraded bios (completly black screen and cmos clean does nothing). Really really unstable beasts.....
Thanks a lot for the support, I'll get back here has soon as waranty does its job.

Arch Linux

#1 2012-12-23 19:27:18

Can't boot using EFISTUB

#2 2012-12-23 19:40:42

Re: Can't boot using EFISTUB

#3 2012-12-23 20:02:50

Re: Can't boot using EFISTUB

#4 2012-12-23 20:38:19

Re: Can't boot using EFISTUB

#5 2012-12-23 20:43:11

Re: Can't boot using EFISTUB

#6 2012-12-23 21:01:04

Re: Can't boot using EFISTUB

#7 2012-12-23 21:25:06

Re: Can't boot using EFISTUB

#8 2012-12-23 23:27:36

Re: Can't boot using EFISTUB

#9 2012-12-23 23:31:53

Re: Can't boot using EFISTUB

#10 2012-12-24 01:21:33

Re: Can't boot using EFISTUB

Board footer