Kernel 3.7 doesn't boot using EFI Stub

cfr · 2013-04-30 23:07:37

srs5694 wrote:

cfr, your EFI version is fairly old, although it looks like the recent kernel patch is returning EFI_UNSUPPORTED only for pre-2.0 EFIs, so if the cause for you is that the call isn't supported on your EFI, that patch won't help -- but another one that's a bit "smarter" might.

I updated the BIOS really recently. Wouldn't that have updated the EFI firmware? Is there something else I can/should do?

I don't know why the framebuffer sizes on our three systems are different -- although WonderWoofy hasn't posted resolution data, so his might be running at a different resolution than the 1024x768x32 used by both my and cfr's computers.

My screen is actually 1366x768. Should my resolution match WonderWoofy's?

srs5694 · 2013-05-01 16:55:22

cfr wrote:

I updated the BIOS really recently. Wouldn't that have updated the EFI firmware? Is there something else I can/should do?

Not necessarily. The version numbers under discussion (such as 2.00 and 2.31) are (semi-)standardized version of the EFI portion of the firmware. Actual shipping firmware includes both the EFI component and some stuff that runs under the EFI to do hardware initialization, as well as bug fixes and whatnot created by the firmware vendor. Chances are a vendor will stick with whatever EFI version they first used on a computer when issuing updates, so if your computer came with an EFI 2.00 firmware, it will use that version even if you update to a firmware that was released a year later. That new version might have bug fixes to the EFI component and to other components, but it will still be an EFI 2.00. Of course, a manufacturer might update the EFI version, too; but this isn't required, and my impression is that such updates are pretty rare.

My screen is actually 1366x768. Should my resolution match WonderWoofy's?

Not necessarily. The screen resolution depends on a number of factors, such as the native resolution of your monitor, the type of video connector (VGA, DVI/HDMI, etc.), the resolutions supported by the firmware, the resolution set by any pre-boot software like GRUB or rEFInd, and perhaps other factors. If System X is using one resolution and System Y is using another, though, it's understandable that their video buffer sizes would differ.

cfr · 2013-05-01 23:13:25

Thank you for the explanation, as always.

My screen is just the laptop screen and is native 1366x768 so I'm not sure if it should be showing as 1024x768 but that is definitely not the native resolution.

WonderWoofy · 2013-05-02 00:41:02

cfr wrote:

Thank you for the explanation, as always.
My screen is just the laptop screen and is native 1366x768 so I'm not sure if it should be showing as 1024x768 but that is definitely not the native resolution.

I think the specific part in srs5694's post that says the resolution might be "set by any pre-boot software like GRUB or rEFInd" might be the key factor here.

cfr · 2013-05-13 23:50:21

By the way, this has applied to every kernel I've tried from 3.8.* up (i.e. including the latest 3.9.2-1), even with the alternative refind binary. (I actually only tried this once.)

It is deadly consistent for me and I'm really curious if I'm actually seeing the same bug or not for just that reason. Seems weird that it is so inconsistent for others but so consistent for me.

farseerfc · 2013-05-17 20:05:39

Just came here from: https://bbs.archlinux.org/viewtopic.php?pid=1274338

Report for statics, my bootctl:

  Firmware: UEFI 2.31 (INSYDE Corp. 4096.01)

my dmesg | grep efi:

[    0.000000] efi: EFI v2.31 by INSYDE Corp.
[    0.000000] efi:  ACPI=0x9affe000  ACPI 2.0=0x9affe014  SMBIOS=0x9aebcb98 
[    0.000000] efi: mem00: type=3, attr=0xf, range=[0x0000000000000000-0x0000000000001000) (0MB)
...
[    0.000000] efi: mem10: type=5, attr=0x800000000000000f, range=[0x0000000000088000-0x00000000000a0000) (0MB)
...
[    1.290304] efifb: probing for efifb
[    1.290613] efifb: framebuffer at 0xc0000000, mapped to 0xffffc90021300000, using 3072k, total 3072k
[    1.290614] efifb: mode is 1024x768x32, linelength=4096, pages=1
[    1.290615] efifb: scrolling: redraw
[    1.290617] efifb: Truecolor: size=8:8:8:8, shift=24:16:8:0
[    1.636563] [Firmware Bug]: efi: Inconsistent initial sizes
[    2.275225] tsc: Refined TSC clocksource calibration: 2095.240 MHz

This is all kernels I have tested:

WORK /var/cache/pacman/pkg/linux-3.8.11-1-x86_64.pkg.tar.xz: packager = Tobias Powalowski <tpowa@archlinux.org>
FAIL /var/cache/pacman/pkg/linux-3.9.2-1-x86_64.pkg.tar.xz: packager = Thomas Bächler <thomas@archlinux.org>
WORK /var/cache/pacman/pkg/linux-3.8.10-1-x86_64.pkg.tar.xz: packager = Tobias Powalowski <tpowa@archlinux.org>

work means work with uefi+gummiboot+efi stub.

eumel · 2013-05-21 17:51:08

3.9.3-1 is once again broken for me. 3.9.3-1 in ck as well. It worked up to and including 3.9.2. I am using gummiboot (and refind) on a ThinkPad X230.

HeptaSean · 2013-05-21 19:56:50

eumel wrote:

3.9.3-1 is once again broken for me. 3.9.3-1 in ck as well. It worked up to and including 3.9.2. I am using gummiboot (and refind) on a ThinkPad X230.

Just had the first breakage of this kind with linux-3.9.3-1 (solved by downgrading to linux-3.9.2-1 and IgnorePkg'ing linux). I am using refind-efi and the EFISTUB loader in the kernel.

Since installing Arch on 11th April, all other combinations of kernels and refind-efi worked:

sean@leeloo ~ $ cat /var/log/pacman.log | grep "ed linux "
[2013-04-11 00:33] installed linux (3.8.6-1)
[2013-04-15 18:35] [PACMAN] upgraded linux (3.8.6-1 -> 3.8.7-1)
[2013-04-21 05:42] [PACMAN] reinstalled linux (3.8.7-1)
[2013-04-21 05:44] [PACMAN] reinstalled linux (3.8.7-1)
[2013-04-23 04:35] [PACMAN] upgraded linux (3.8.7-1 -> 3.8.8-1)
[2013-04-26 01:15] [PACMAN] upgraded linux (3.8.8-1 -> 3.8.8-2)
[2013-04-29 21:25] [PACMAN] upgraded linux (3.8.8-2 -> 3.8.10-1)
[2013-05-04 14:32] [PACMAN] upgraded linux (3.8.10-1 -> 3.8.11-1)
[2013-05-14 04:25] [PACMAN] upgraded linux (3.8.11-1 -> 3.9.2-1)
[2013-05-21 20:22] [PACMAN] upgraded linux (3.9.2-1 -> 3.9.3-1)
[2013-05-21 20:52] [PACMAN] downgraded linux (3.9.3-1 -> 3.9.2-1)
sean@leeloo ~ $ cat /var/log/pacman.log | grep "ed refind-efi "
[2013-04-11 03:14] [PACMAN] installed refind-efi (0.6.8-1)
[2013-05-07 02:17] [PACMAN] upgraded refind-efi (0.6.8-1 -> 0.6.10-1)
[2013-05-21 20:22] [PACMAN] upgraded refind-efi (0.6.10-1 -> 0.6.11-1)

I haven't tested downgrading refind-efi instead of linux, though.

This is on a Thinkpad T430s (so, again, Lenovo, like everyone else in this thread):

sean@leeloo ~ $ bootctl 
System:
   Machine ID: 04c9cbaeaed5442aa7677732e8ff7148
      Boot ID: b792f3a3075c4e1d84a4a2c61b4a119a

Selected Firmware Entry:
        Title: rEFInd
    Partition: /dev/disk/by-partuuid/6eb0c56f-8243-456b-95b6-f042d9b1cad6
         File: └─/EFI/refind/refind_x64.efi

No suitable data is provided by the boot manager. See:
  http://www.freedesktop.org/wiki/Software/systemd/BootLoaderInterface
  http://www.freedesktop.org/wiki/Specifications/BootLoaderSpec
for details.

sean@leeloo ~ $ dmesg | grep efi | head -n 2
[    0.000000] efi: EFI v2.31 by Lenovo
[    0.000000] efi:  ACPI=0xdaffe000  ACPI 2.0=0xdaffe014  SMBIOS=0xdae9e000

I'm just keeping linux in IgnorePkg until some solution is found (or a new kernel is there to test).

Best regards
Ben

cfr · 2013-05-21 20:55:42

3.9.3-1 doesn't work for me either. Would sure love to know why it is so damn *consistent* in my case and so inconsistent for everyone else!

eumel · 2013-05-21 21:47:43

Okay. Here it goes.

Due to 3.9.3-1 failing, I downgraded to 3.9.2. This worked. I also installed 3.9.3-ck from repo-ck, which failed just like 3.9.3-ARCH. So far no surprises. I then went ahead and tried to create an EFISTUB entry using efibootmgr for 3.9.3-ck, using the following command:

efibootmgr -c -d /dev/sda -p 1 -L "Arch Linux (CK)" -l '\vmlinuz-linux-ck' -u initrd=/initramfs-linux-ck.img root=LABEL=system ro quiet rootflags=su
bvol=__active add_efi_memmap acpi_backlight=vendor pcie_aspm=force nmi_watchdog=0 elevator=noop

This did indeed boot 3.9.3-ck. The real surprise is: now I can boot the (unmodified) 3.9.3-ck using gummiboot. As I said, this did not work before. I went ahead and deleted the boot entry I created before for the kernel itself. Still, gummiboot + 3.9.3-ck worked (what?!). Being intrigued now, I upgraded back to 3.9.3-ARCH. And it booted using gummiboot! Wait, what?! I really do not get this, but everything works now.

This is ridiculous. Lenovo's firmware must be seriously broken?

So you may want to try creating a boot entry for the "pure" kernel.

Edit: "acpi_backlight=vendor pcie_aspm=force nmi_watchdog=0 elevator=noop" has of course nothing to do with this.
Edit2: Also, in the gummiboot entry there is no add_efi_memmap.

/boot/loader/entries/arch.conf:
title   Arch Linux
linux   \vmlinuz-linux
initrd  \initramfs-linux.img
options root=/dev/sda2 rootflags=subvol=__active pcie_aspm=force nmi_watchdog=0 acpi_backlight=vendor elevator=noop ro quiet

Last edited by eumel (2013-05-21 21:51:31)

soulthreads · 2013-05-22 13:00:48

Wow, that strange magic (creating EFISTUB entry for kernel) worked very well for me too. Thank you, eumel! I think I'll leave this entry there for such emergency situations.

schlehmil · 2013-05-23 05:28:33

eumel wrote:

Okay. Here it goes.
Due to 3.9.3-1 failing, I downgraded to 3.9.2. This worked. I also installed 3.9.3-ck from repo-ck, which failed just like 3.9.3-ARCH. So far no surprises. I then went ahead and tried to create an EFISTUB entry using efibootmgr for 3.9.3-ck, using the following command:
efibootmgr -c -d /dev/sda -p 1 -L "Arch Linux (CK)" -l '\vmlinuz-linux-ck' -u initrd=/initramfs-linux-ck.img root=LABEL=system ro quiet rootflags=su
bvol=__active add_efi_memmap acpi_backlight=vendor pcie_aspm=force nmi_watchdog=0 elevator=noop
This did indeed boot 3.9.3-ck. The real surprise is: now I can boot the (unmodified) 3.9.3-ck using gummiboot. As I said, this did not work before. I went ahead and deleted the boot entry I created before for the kernel itself. Still, gummiboot + 3.9.3-ck worked (what?!). Being intrigued now, I upgraded back to 3.9.3-ARCH. And it booted using gummiboot! Wait, what?! I really do not get this, but everything works now.
This is ridiculous. Lenovo's firmware must be seriously broken?
So you may want to try creating a boot entry for the "pure" kernel.
Edit: "acpi_backlight=vendor pcie_aspm=force nmi_watchdog=0 elevator=noop" has of course nothing to do with this.
Edit2: Also, in the gummiboot entry there is no add_efi_memmap.
/boot/loader/entries/arch.conf:
title   Arch Linux
linux   \vmlinuz-linux
initrd  \initramfs-linux.img
options root=/dev/sda2 rootflags=subvol=__active pcie_aspm=force nmi_watchdog=0 acpi_backlight=vendor elevator=noop ro quiet

Thank you eumel. That works for me as well. (Thinkpad T430s with EFI only boot) Should someone report this to Lenovo or may it be an issue inside the kernel? Actually I do not understand what changed inside the EFI boot after manually adding the EFISTUB entry.

eumel · 2013-05-23 06:53:27

schlehmil wrote:

Thank you eumel. That works for me as well. (Thinkpad T430s with EFI only boot) Should someone report this to Lenovo or may it be an issue inside the kernel? Actually I do not understand what changed inside the EFI boot after manually adding the EFISTUB entry.

You're welcome! My guess is that some efivars changed. Someone with more knowledge about EFI might look into this.

HeptaSean · 2013-05-24 00:38:46

eumel wrote:

So you may want to try creating a boot entry for the "pure" kernel.

Works for me, too (native UEFI boot entry as well as gummiboot, even after deleting the native entry again).

And I also have no clue, why this should work. Makes no sense at all.

Anyway: Thank you, eumel!

By the way: It was a bit of a hassle to create the boot entries, since efibootmgr does not work with newer kernels on my machine (probably due to http://askubuntu.com/a/294372), but the only old kernel that I could get without compiling was the LTS kernel, which is so old, that it a) cannot be loaded by gummiboot (no EFISTUB?), only by grub-efi and b) has some other flaws when starting my usual X environment (graphics errors, kernel panics due to skype, …).

I finally downloaded the archboot LTS version from https://wiki.archlinux.org/index.php/Ar … cue_system, created a grub entry for that and used the efibootmgr in there. …

HeptaSean · 2013-05-24 01:01:16

cfr wrote:

3.9.3-1 doesn't work for me either. Would sure love to know why it is so damn *consistent* in my case and so inconsistent for everyone else!

You wrote in an earlier post:

cfr wrote:

I don't keep the kernel etc. on the ESP but use the ext4 driver to load from /boot.

Perhaps, that is the problem?

I suppose, most of the other people in this thread follow the various guides and put the kernel on the ESP (I have to, since everything else is encrypted).

But, after switching to gummiboot, I followed the advice there and mount the ESP directly as /boot and not as /boot/efi. That way, I do not have to copy kernels around, but they are installed directly in the right place by the package. This does work well with gummiboot and grub-efi, but probably not with the autodetection of refind.

WonderWoofy · 2013-05-24 02:05:16

It works fine with the autodetection of rEFInd. REFInd actually works quite well with the kernels on the ESP, and was only recently that Rod Smith added the ext4 driver to the available filesystem drivers included with refind.

Edit: Way OT, but I have always wondered... if rEFInd has EFI capitalized, it is therefore written in a *very* specific way. So if it starts a sentence like above, does it then get a capital 'R' like I did above? Or does it stick it its specific capitalization since that seems like an important visual queue?

Last edited by WonderWoofy (2013-05-24 02:07:20)

HeptaSean · 2013-05-24 08:11:16

WonderWoofy wrote:

It works fine with the autodetection of rEFInd. REFInd actually works quite well with the kernels on the ESP, and was only recently that Rod Smith added the ext4 driver to the available filesystem drivers included with refind.

OK, I was too brief.

What I meant was that I now have:

sean@leeloo ~ $ mount | grep /boot
/dev/sda1 on /boot type vfat (rw,relatime,fmask=0022,dmask=0022,codepage=437,iocharset=iso8859-1,shortname=mixed,errors=remount-ro)
sean@leeloo ~ $ ls -l /boot/
total 138696
drwxr-xr-x 5 root root      4096 May 23 22:45 EFI
-rwxr-xr-x 1 root root   3224064 May 24 01:43 archboot
drwxr-xr-x 6 root root      4096 May 24 02:16 grub
-rwxr-xr-x 1 root root 111453834 May 22 06:16 initramfs-archboot.img
-rwxr-xr-x 1 root root  17063074 May 23 23:14 initramfs-linux-fallback.img
-rwxr-xr-x 1 root root   5632451 May 23 23:14 initramfs-linux.img
drwxr-xr-x 3 root root      4096 May 22 06:39 loader
-rwxr-xr-x 1 root root    847232 May 23 05:38 shellx64.efi
-rwxr-xr-x 1 root root   3778464 May 19 22:53 vmlinuz-linux

The things in /boot/EFI are automatically installed there by gummiboot install and grub-install --target=x86_64-efi --efi-directory=/boot --bootloader-id=arch_grub --recheck (which also installs most of the things in /boot/grub except for the configuration):

sean@leeloo ~ $ ls -lR /boot/EFI/
/boot/EFI/:
total 12
drwxr-xr-x 2 root root 4096 May 23 22:51 BOOT
drwxr-xr-x 2 root root 4096 May 23 22:45 arch_grub
drwxr-xr-x 2 root root 4096 May 23 22:51 gummiboot

/boot/EFI/BOOT:
total 84
-rwxr-xr-x 1 root root 83608 Apr 12 14:58 BOOTX64.EFI

/boot/EFI/arch_grub:
total 116
-rwxr-xr-x 1 root root 116736 May 23 22:45 grubx64.efi

/boot/EFI/gummiboot:
total 84
-rwxr-xr-x 1 root root 83608 Apr 12 14:58 gummibootx64.efi

The vmlinuz-linux kernel and its initramfs-linux.img and initramfs-linux-fallback.img are automatically placed there (directly in /boot) by the linux package on upgrades (and by mkinitcpio). So, there is no manual (or scripted) copying of them to a subdirectory of /boot/EFI.

archboot (the LTS kernel of Archboot), initramfs-archboot.img and shellx64.efi were manually copied there for rescue purposes.

/boot/grub/grub.cfg was generated by grub-mkconfig -o /boot/grub/grub.cfg. It automatically found the vmlinuz-linux kernel and for Archboot, I have this:

sean@leeloo ~ $ cat /etc/grub.d/40_custom 
#!/bin/sh
exec tail -n +3 $0
# This file provides an easy way to add custom menu entries.  Simply type the
# menu entries you want to add after this comment.  Be careful not to change
# the 'exec tail' line above.
menuentry 'Archboot (Rescue system with LTS kernel)' {
	load_video
	set gfxpayload=keep
	insmod gzio
	insmod part_gpt
	insmod fat
	echo	'Loading Archboot kernel ...'
	linux	/archboot
	echo	'Loading Archboot initial ramdisk ...'
	initrd	/initramfs-archboot.img
}

For gummiboot, there is the configuration under /boot/loader:

sean@leeloo ~ $ cat /boot/loader/loader.conf 
default arch-autodetect
sean@leeloo ~ $ ls /boot/loader/entries
arch-autodetect.conf  arch-fallback.conf    grub.conf
sean@leeloo ~ $ cat /boot/loader/entries/arch-autodetect.conf 
title          Arch Linux
linux          /vmlinuz-linux
initrd         /initramfs-linux.img
options        cryptdevice=/dev/sda2:main:allow-discards root=/dev/mapper/main-root ro resume=/dev/mapper/main-swap
sean@leeloo ~ $ cat /boot/loader/entries/arch-fallback.conf 
title          Arch Linux (Fallback Initrd)
linux          /vmlinuz-linux
initrd         /initramfs-linux-fallback.img
options        cryptdevice=/dev/sda2:main:allow-discards root=/dev/mapper/main-root ro resume=/dev/mapper/main-swap
sean@leeloo ~ $ cat /boot/loader/entries/grub.conf 
title          GRUB Bootloader
efi            /EFI/arch_grub/grubx64.efi

This all works quite well.

The documentation of rEFInd says: “It scans most of the subdirectories of the EFI directory on every filesystem it can access for files with names that end in .efi.”

Since the kernel that is automatically installed is neither in a subdirectory of /boot/EFI nor does it have a .efi extension, I suppose that autodetection does not work with this setup. It might be possible to write a manual configuration for rEFInd, though.

Edit: Way OT, but I have always wondered... if rEFInd has EFI capitalized, it is therefore written in a *very* specific way. So if it starts a sentence like above, does it then get a capital 'R' like I did above? Or does it stick it its specific capitalization since that seems like an important visual queue?

I'd say that proper names with minuscules at the beginning should keep them even if at the beginning of a sentence. Probably, it's a matter of taste (or style guide).

Last edited by HeptaSean (2013-05-24 09:38:14)

WonderWoofy · 2013-05-24 13:42:35

Oh sorry, man. I think I was actually too brief probably. I understand exactly what your situation was with mounting the ESP on /boot directly. I do this too, though I have systemd move crap around for me to keep a decent heirarchy in the ESP. But when I first started using UEFI, I had what I think was a firmware bug that wouldn't allow me to enter a path past the root of the ESP with a direct efibootmgr entry, so I was forced to use the ESP on /boot (which tuend out the be awesome). I was actually referencing your suggestion thta cfr's problem might be that he is using /boot/efi/EFI/etc and keeping his kernels on /boot itself.

@cfr, I wonder if you just copied your kernel and initramfs onto the ESP and then created an efibootmgr entry, you could still use the current config, but maybe then you could enjoy this success that others seem to be having?

Last edited by WonderWoofy (2013-05-24 13:43:54)

SNCPlay42 · 2013-05-24 14:19:28

Hi,

I'm not sure whether this is a related issue, but since I upgraded the kernel from 3.9.2-1 to 3.9.3-1, I can't boot the stock kernel unless I wait about 10 seconds after the bootloader (any bootloader it seems, I've tested this with both rEFInd and GRUB2) starts up. Otherwise, the computer just freezes on the "booting..." screen.

Maybe this is the same problem other people are experiencing? I imagine EFISTUB doesn't give much opportunity to wait...

For what it's worth,

[    0.000000] efi: EFI v2.31 by American Megatrends

jarryson · 2013-05-24 15:44:31

3.9.3 break gummiboot here, too. And I don't know what to do.

I have to use grub2 on mobile storage device to boot arch. it's annoying

HeptaSean · 2013-05-24 16:02:44

SNCPlay42 wrote:

I'm not sure whether this is a related issue, but since I upgraded the kernel from 3.9.2-1 to 3.9.3-1, I can't boot the stock kernel unless I wait about 10 seconds after the bootloader (any bootloader it seems, I've tested this with both rEFInd and GRUB2) starts up. Otherwise, the computer just freezes on the "booting..." screen.
Maybe this is the same problem other people are experiencing? I imagine EFISTUB doesn't give much opportunity to wait...

You could wait on the gummiboot menu. … Never tried that.

But your problem sounds very similar. Perhaps, the solution found by eumel above also works for you?

Could you try efibootmgr -c -L "Arch Linux" -l "\<path to your kernel relative to EFI partition>" -u initrd=/<path to your initramfs relative to EFI partition> <your other boot options>?
(Verify that it worked correctly – especially that the options are complete – by efibootmgr -v. All invocations of efibootmgr have to be as root or with sudo.)

jarryson wrote:

3.9.3 break gummiboot here, too. And I don't know what to do.
I have to use grub2 on mobile storage device to boot arch. it's annoying

The least you could do is install grub on the hard drive.

And you could try the solution posted by eumel, above – creating a boot entry for the linux kernel directly in the efivars (the command line in my response to SNCPlay42).
(If efibootmgr does not create an entry, then you probably-perhaps are hit by the same bug as I am and have to use an old kernel to call efibootmgr, either linux-lts or some installation medium or rescue system.)

SNCPlay42 · 2013-05-24 16:37:15

HeptaSean wrote:

(If efibootmgr does not create an entry, then you probably-perhaps are hit by the same bug as I am and have to use an old kernel to call efibootmgr, either linux-lts or some installation medium or rescue system.)

What're the symptoms of this? My efibootmgr's just exiting (code 1) without printing anything. Quick strace says it's getting ENOSPC trying to write the var. (Side rant on efibootmgr: Why on earth doesn't it print ANY diagnostic messages ever? There really should be a better way than running strace). Thing is it worked when I created rEFInd's entry yesterday with the same kernel... I really hope I haven't actually ran out of space wherever the EFI vars are stored.

Anyway, rebooting to install medium now...

Edit

...And I'm back, after failing to boot from my usbdrive (neither the internal grub2 or the EFI grub-legacy on the usb drive can find my usb drive it seems), remembering I have the install medium copied onto my /boot, and manually entering the options to boot that. Seems the efibootmgr on that magically works fine, and I created the entry to boot the kernel directly, and that does, indeed, boot fine directly. So should that now work from rEFInd as well, if I'm reading eumel's post right? Anybody know if it actually has to be the same file? I copied the kernel from my / partition's /boot to the EFI partition, but rEFInd uses the one actually in /boot as placed there by Arch.

I guess I could just stick with using the direct boot entry and set Arch up to copy kernels to the system partition or something. I guess I don't really need rEFInd if that works. I wanted it to also boot That Other OS, but since that installed itself using legacy BIOS...

Last edited by SNCPlay42 (2013-05-24 17:15:25)

blackout23 · 2013-05-24 16:56:15

Linux 3.9.3-ARCH works fine with Gummiboot on my ASUS P8Z86-V Pro. ESP is FAT32 and kernel image is in its root.

SNCPlay42 · 2013-05-24 17:12:10

Yep, It seems having a direct entry for the same kernel in a different file on a different partition is still enough to magically make booting via rEFInd work.

EFI, how does it work?

WonderWoofy · 2013-05-24 17:13:47

I have not had these issues for some time, but I realized that I have had direct efibootmgr entries for some time as backups. I keep them disabled, but they are there...

Arch Linux

#226 2013-04-30 23:07:37

Re: Kernel 3.7 doesn't boot using EFI Stub

#227 2013-05-01 16:55:22

Re: Kernel 3.7 doesn't boot using EFI Stub

#228 2013-05-01 23:13:25

Re: Kernel 3.7 doesn't boot using EFI Stub

#229 2013-05-02 00:41:02

Re: Kernel 3.7 doesn't boot using EFI Stub

#230 2013-05-13 23:50:21

Re: Kernel 3.7 doesn't boot using EFI Stub

#231 2013-05-17 20:05:39

Re: Kernel 3.7 doesn't boot using EFI Stub

#232 2013-05-21 17:51:08

Re: Kernel 3.7 doesn't boot using EFI Stub

#233 2013-05-21 19:56:50

Re: Kernel 3.7 doesn't boot using EFI Stub

#234 2013-05-21 20:55:42

Re: Kernel 3.7 doesn't boot using EFI Stub

#235 2013-05-21 21:47:43

Re: Kernel 3.7 doesn't boot using EFI Stub

#236 2013-05-22 13:00:48

Re: Kernel 3.7 doesn't boot using EFI Stub

#237 2013-05-23 05:28:33

Re: Kernel 3.7 doesn't boot using EFI Stub

#238 2013-05-23 06:53:27

Re: Kernel 3.7 doesn't boot using EFI Stub

#239 2013-05-24 00:38:46

Re: Kernel 3.7 doesn't boot using EFI Stub

#240 2013-05-24 01:01:16

Re: Kernel 3.7 doesn't boot using EFI Stub

#241 2013-05-24 02:05:16

Re: Kernel 3.7 doesn't boot using EFI Stub

#242 2013-05-24 08:11:16

Re: Kernel 3.7 doesn't boot using EFI Stub

#243 2013-05-24 13:42:35

Re: Kernel 3.7 doesn't boot using EFI Stub

#244 2013-05-24 14:19:28

Re: Kernel 3.7 doesn't boot using EFI Stub

#245 2013-05-24 15:44:31

Re: Kernel 3.7 doesn't boot using EFI Stub

#246 2013-05-24 16:02:44

Re: Kernel 3.7 doesn't boot using EFI Stub

#247 2013-05-24 16:37:15

Re: Kernel 3.7 doesn't boot using EFI Stub

Edit

#248 2013-05-24 16:56:15

Re: Kernel 3.7 doesn't boot using EFI Stub

#249 2013-05-24 17:12:10

Re: Kernel 3.7 doesn't boot using EFI Stub

#250 2013-05-24 17:13:47

Re: Kernel 3.7 doesn't boot using EFI Stub

Board footer