Kernel 3.7 doesn't boot using EFI Stub

HeptaSean · 2013-05-27 07:22:54

WonderWoofy wrote:

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.

Actually, I was suggesting that maybe the problem is that he does not have the kernels on the EFI partition at all:

cfr wrote:

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

Perhaps, the ext4 driver not working or something.

@cfr, any news?

SNCPlay42 wrote:

HeptaSean wrote:
If efibootmgr does not create an entry, then you probably-perhaps are hit by the same bug as I am […]
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.

Exactly the same symptoms, here. So, yes, probably the same.

I found a description of this, here: http://askubuntu.com/questions/286462/1 … 372#294372

This refers to a kernel patch from March: http://lkml.indiana.edu/hypermail/linux … 00887.html and https://git.kernel.org/cgit/linux/kerne … 8d1e140750

(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).

Since the kernel patch is pretty new, they probably did not come to include a diagnostic for that. …

Thing is it worked when I created rEFInd's entry yesterday with the same kernel...

That is strange (or you just hit the condition for ENOSPC with this write, see below).

I really hope I haven't actually ran out of space wherever the EFI vars are stored.

Probably not. The mail that describes the necessity of the patch (the LKML link above) says that some firmwares become unbootable if more than half of the flash storage for the variables is in use. So, the kernel now refuses to write with ENOSPC if that is the case.

cfr · 2013-05-27 22:30:09

No. I've had no luck. I've been meaning to try the direct boot entry trick to see if that does anything but haven't got around to it yet. (Been fiddling with fonts instead.)

I don't think the ext4 driver can not be working else I assume rEFInd would complain that it could not find the kernel etc. at all rather than apparently trying to start it and failing. I think rEFInd hands off to the kernel fine and whatever goes wrong goes wrong at that point.

cfr · 2013-05-28 00:31:14

Question: do efibootmgr entries always look very odd when using the stub loader directly? In particular, does it add a dot after every character in the additional arguments passed via -u? I tried with and without quotes and got just the same results but it certainly looks all wrong!

WonderWoofy · 2013-05-28 00:59:09

You mean like this?

Boot0016  Arch Linux (Offical Kernel)	HD(1,800,200000,664909aa-c06a-45cb-b67c-9e533c8d057f)File(\EFI\arch\vmlinuz-linux.efi)r.o.o.t.=./.d.e.v./.m.a.p.p.e.r./.v.o.l.g.r.p.0.-.r.o.o.t._.a.r.c.h. .i.n.i.t.r.d.=.\.E.F.I.\.a.r.c.h.\.i.n.i.t.r.a.m.f.s.-.l.i.n.u.x...i.m.g. .a.d.d._.e.f.i._.m.e.m.m.a.p. .l.i.b.a.h.c.i...i.g.n.o.r.e._.s.s.s.=.1. .q.u.i.e.t. .a.c.p.i._.o.s.i.=.".!.W.i.n.d.o.w.s. .2.0.1.2."...

Yes this is normal. I am not sure why it does that, but if it looks similar to that then it is right.

cfr · 2013-05-28 01:25:15

Yes, I meant exactly that. (Well, not Windows but the dots bit.) Thanks for confirming that it really is normal for it to look that way.

WonderWoofy · 2013-05-28 01:29:44

cfr wrote:

Yes, I meant exactly that. (Well, not Windows but the dots bit.) Thanks for confirming that it really is normal for it to look that way.

Well, the acpi_osi="!Windows 2012" simply means that it is not windows 2012. This makes my backlight keys function correctly.

cfr · 2013-05-28 01:42:32

WonderWoofy wrote:

cfr wrote:
Yes, I meant exactly that. (Well, not Windows but the dots bit.) Thanks for confirming that it really is normal for it to look that way.
Well, the acpi_osi="!Windows 2012" simply means that it is not windows 2012. This makes my backlight keys function correctly.

Sorry. I didn't read it very carefully since I assumed that the details would differ anyway - I just registered it had something about Windows in it. I was really looking at the dots and not the bits in between .

WonderWoofy · 2013-05-28 01:53:59

cfr wrote:

WonderWoofy wrote:
cfr wrote:
Yes, I meant exactly that. (Well, not Windows but the dots bit.) Thanks for confirming that it really is normal for it to look that way.
Well, the acpi_osi="!Windows 2012" simply means that it is not windows 2012. This makes my backlight keys function correctly.
Sorry. I didn't read it very carefully since I assumed that the details would differ anyway - I just registered it had something about Windows in it. I was really looking at the dots and not the bits in between .

Heh, I just didn't want you to think I had lost my way

cfr · 2013-05-28 22:32:42

Well, the solution does not work for me, anyway. All I did was trigger a kernel panic. (Apparently efibootmgr does zero sanity checking on its arguments which seems a bit of an oversight although I admit the mistake in feeding it was mine.)

I cannot boot the stub directly. And having the direct entries does not magically enable rEFInd to work.

It definitely finds the initramfs etc. I know this because when I set it up initially, I made a mistake and it complained volubly. When, on the other hand, I had the path correct, I just get nothingness - a blank screen, backlit but nothing else, with the stub loader.

So, I would still love to know why this is so incredibly consistent for me and so inconsistent for everyone else. (For me, nothing in 3.8.* or 3.9.* works whereas all kernels prior to that booted with rEFInd just fine.)

I set up the stub loader to use a kernel and initramfs under \EFI\arch\, in case that makes any difference (i.e. at /boot/efi/EFI/arch/).

WonderWoofy · 2013-05-28 22:56:29

Honestly, with the amount of UEFI issues I have seen you experience over my time in these forums, I think it is just buggy firmware you've got there. I can think of no other reasonable explanation.

That said, I don't know if you recall back when I had some UEFI troubles when I first tried to set up direct efistub booting. But my system would refuse to boot unless I put the kernel and initramfs in the root of the ESP. It turned out that the efibootmgr command (or probably that version of the firmware) was truncating things when writing it to the nvram. So I wonder, if you haven't already removed them, if you can post the added entry here. By that I mean the output of "efibootmgr -v".

cfr · 2013-05-29 02:49:35

I may have done something wrong but it is not truncating it:

BootCurrent: 000B
Timeout: 0 seconds
BootOrder: 000B,000A,0007,0005,0008,0006,000C,000D
Boot0000  Setup
Boot0001  Boot Menu
Boot0002  Diagnostic Splash
Boot0003  Rescue and Recovery
Boot0004  Startup Interrupt Menu
Boot0005* USB CD:       030a2400d23878bc820f604d8316c068ee79d25b86701296aa5a7848b66cd49dd3ba6a55
Boot0006* USB FDD       030a2400d23878bc820f604d8316c068ee79d25b6ff015a28830b543a8b8641009461e49
Boot0007* ATA HDD0:     030a2500d23878bc820f604d8316c068ee79d25b91af625956449f41a7b91f4f892ab0f600
Boot0008* USB HDD       030a2400d23878bc820f604d8316c068ee79d25b33e821aaaf33bc4789bd419f88c50803
Boot0009  PCI LAN       030a2400d23878bc820f604d8316c068ee79d25b78a84aaf2b2afc4ea79cf5cc8f3d3803
Boot000A* Arch Linux (GRUB2)    HD(1,800,200000,f28c8824-79f1-4f97-83c6-f6a551aa4e79)File(\EFI\arch_grub\grubx64.efi)
Boot000B* Arch Linux (rEFInd)   HD(1,800,200000,f28c8824-79f1-4f97-83c6-f6a551aa4e79)File(\EFI\arch_refind\refind_x64.efi)
Boot000C* Arch Linux (EFI)      HD(1,800,200000,f28c8824-79f1-4f97-83c6-f6a551aa4e79)File(\EFI\arch\vmlinuz-linux)i.n.i.t.r.d.=./.E.F.I./.a.r.c.h./.i.n.i.t.r.a.m.f.s.-.l.i.n.u.x...i.m.g. .r.o.o.t.=./.d.e.v./.v.g.r.o.u.p.-.c.f.r./.a.r.c.h. .r.o. .r.o.o.t.f.s.t.y.p.e.=.e.x.t.4. .c.r.y.p.t.d.e.v.i.c.e.=./.d.e.v./.d.i.s.k./.b.y.-.u.u.i.d./.5.2.c.6.4.5.9.e.-.e.2.7.a.-.4.0.0.f.-.a.2.8.2.-.f.7.3.3.3.7.d.7.0.f.7.4.:.l.v.m. .r.e.s.u.m.e.=./.d.e.v./.v.g.r.o.u.p.-.c.f.r./.s.w.a.p. .p.c.i.e._.a.s.p.m.=.f.o.r.c.e. .i.9.1.5...i.9.1.5._.e.n.a.b.l.e._.r.c.6.=.-.1. .i.9.1.5...i.9.1.5._.e.n.a.b.l.e._.f.b.c.=.1. .i.9.1.5...l.v.d.s._.d.o.w.n.c.l.o.c.k.=.1. .i.9.1.5...s.e.m.a.p.h.o.r.e.s.=.1. .a.d.d._.e.f.i._.m.e.m.m.a.p...
Boot000D* Arch Linux (EFI Fallback)     HD(1,800,200000,f28c8824-79f1-4f97-83c6-f6a551aa4e79)File(\EFI\arch\vmlinuz-linux)i.n.i.t.r.d.=./.E.F.I./.a.r.c.h./.i.n.i.t.r.a.m.f.s.-.l.i.n.u.x.-.f.a.l.l.b.a.c.k...i.m.g. .r.o.o.t.=./.d.e.v./.v.g.r.o.u.p.-.c.f.r./.a.r.c.h. .r.o. .r.o.o.t.f.s.t.y.p.e.=.e.x.t.4. .c.r.y.p.t.d.e.v.i.c.e.=./.d.e.v./.d.i.s.k./.b.y.-.u.u.i.d./.5.2.c.6.4.5.9.e.-.e.2.7.a.-.4.0.0.f.-.a.2.8.2.-.f.7.3.3.3.7.d.7.0.f.7.4.:.l.v.m. .r.e.s.u.m.e.=./.d.e.v./.v.g.r.o.u.p.-.c.f.r./.s.w.a.p. .p.c.i.e._.a.s.p.m.=.f.o.r.c.e. .i.9.1.5...i.9.1.5._.e.n.a.b.l.e._.r.c.6.=.-.1. .i.9.1.5...i.9.1.5._.e.n.a.b.l.e._.f.b.c.=.1. .i.9.1.5...l.v.d.s._.d.o.w.n.c.l.o.c.k.=.1. .i.9.1.5...s.e.m.a.p.h.o.r.e.s.=.1. .a.d.d._.e.f.i._.m.e.m.m.a.p...

WonderWoofy · 2013-05-29 03:52:59

I think with a direct efibootmgr entry it needs to be vmlinuz-linux.efi as it is running as an efi application. Gummiboot and rEFInd do this part for you if you don't have it there.

<OT>
Also, on an unrelated note, all that i915 stuff can be put in /etc/modprobe.d/i915.conf with something like this

% cat /etc/modprobe.d/i915.conf
options i915 lvds_downclock=1 semaphores-1 enable_fbc=1 enable_rc6=-1

I think we have already discussed this in the past, but the rc6 setting is unnecessary, as that is the default.

Also, are you sure you need to use pcie_aspm=force?
</OT>

HeptaSean · 2013-05-29 04:44:16

cfr wrote:

[…]
Boot000A* Arch Linux (GRUB2)    HD(1,800,200000,f28c8824-79f1-4f97-83c6-f6a551aa4e79)File(\EFI\arch_grub\grubx64.efi)
Boot000B* Arch Linux (rEFInd)   HD(1,800,200000,f28c8824-79f1-4f97-83c6-f6a551aa4e79)File(\EFI\arch_refind\refind_x64.efi)
Boot000C* Arch Linux (EFI)      HD(1,800,200000,f28c8824-79f1-4f97-83c6-f6a551aa4e79)File(\EFI\arch\vmlinuz-linux)i.n.i.t.r.d.=./.E.F.I./.a.r.c.h./.i.n.i.t.r.a.m.f.s.-.l.i.n.u.x...i.m.g. .r.o.o.t.=./.d.e.v./.v.g.r.o.u.p.-.c.f.r./.a.r.c.h. .r.o. .r.o.o.t.f.s.t.y.p.e.=.e.x.t.4. .c.r.y.p.t.d.e.v.i.c.e.=./.d.e.v./.d.i.s.k./.b.y.-.u.u.i.d./.5.2.c.6.4.5.9.e.-.e.2.7.a.-.4.0.0.f.-.a.2.8.2.-.f.7.3.3.3.7.d.7.0.f.7.4.:.l.v.m. .r.e.s.u.m.e.=./.d.e.v./.v.g.r.o.u.p.-.c.f.r./.s.w.a.p. .p.c.i.e._.a.s.p.m.=.f.o.r.c.e. .i.9.1.5...i.9.1.5._.e.n.a.b.l.e._.r.c.6.=.-.1. .i.9.1.5...i.9.1.5._.e.n.a.b.l.e._.f.b.c.=.1. .i.9.1.5...l.v.d.s._.d.o.w.n.c.l.o.c.k.=.1. .i.9.1.5...s.e.m.a.p.h.o.r.e.s.=.1. .a.d.d._.e.f.i._.m.e.m.m.a.p...
Boot000D* Arch Linux (EFI Fallback)     HD(1,800,200000,f28c8824-79f1-4f97-83c6-f6a551aa4e79)File(\EFI\arch\vmlinuz-linux)i.n.i.t.r.d.=./.E.F.I./.a.r.c.h./.i.n.i.t.r.a.m.f.s.-.l.i.n.u.x.-.f.a.l.l.b.a.c.k...i.m.g. .r.o.o.t.=./.d.e.v./.v.g.r.o.u.p.-.c.f.r./.a.r.c.h. .r.o. .r.o.o.t.f.s.t.y.p.e.=.e.x.t.4. .c.r.y.p.t.d.e.v.i.c.e.=./.d.e.v./.d.i.s.k./.b.y.-.u.u.i.d./.5.2.c.6.4.5.9.e.-.e.2.7.a.-.4.0.0.f.-.a.2.8.2.-.f.7.3.3.3.7.d.7.0.f.7.4.:.l.v.m. .r.e.s.u.m.e.=./.d.e.v./.v.g.r.o.u.p.-.c.f.r./.s.w.a.p. .p.c.i.e._.a.s.p.m.=.f.o.r.c.e. .i.9.1.5...i.9.1.5._.e.n.a.b.l.e._.r.c.6.=.-.1. .i.9.1.5...i.9.1.5._.e.n.a.b.l.e._.f.b.c.=.1. .i.9.1.5...l.v.d.s._.d.o.w.n.c.l.o.c.k.=.1. .i.9.1.5...s.e.m.a.p.h.o.r.e.s.=.1. .a.d.d._.e.f.i._.m.e.m.m.a.p...

WonderWoofy wrote:

I think with a direct efibootmgr entry it needs to be vmlinuz-linux.efi as it is running as an efi application. Gummiboot and rEFInd do this part for you if you don't have it there.

Actually, no, direct efibootmgr entries do not need the .efi extension. This works for me without problems:

sean@leeloo ~ $ sudo efibootmgr -v
BootCurrent: 0000
Timeout: 0 seconds
BootOrder: 0000,0001,0002,0003,0004,000E,000F,000C,000D,0012
Boot0000* Arch Linux (Default)	HD(1,800,100000,6eb0c56f-8243-456b-95b6-f042d9b1cad6)File(\vmlinuz-linux)i.n.i.t.r.d.=./.i.n.i.t.r.a.m.f.s.-.l.i.n.u.x...i.m.g. .c.r.y.p.t.d.e.v.i.c.e.=./.d.e.v./.s.d.a.2.:.m.a.i.n.:.a.l.l.o.w.-.d.i.s.c.a.r.d.s. .r.o.o.t.=./.d.e.v./.m.a.p.p.e.r./.m.a.i.n.-.r.o.o.t. .r.o. .r.e.s.u.m.e.=./.d.e.v./.m.a.p.p.e.r./.m.a.i.n.-.s.w.a.p...
Boot0001* Arch Linux (Fallback)	HD(1,800,100000,6eb0c56f-8243-456b-95b6-f042d9b1cad6)File(\vmlinuz-linux)i.n.i.t.r.d.=./.i.n.i.t.r.a.m.f.s.-.l.i.n.u.x.-.f.a.l.l.b.a.c.k...i.m.g. .c.r.y.p.t.d.e.v.i.c.e.=./.d.e.v./.s.d.a.2.:.m.a.i.n.:.a.l.l.o.w.-.d.i.s.c.a.r.d.s. .r.o.o.t.=./.d.e.v./.m.a.p.p.e.r./.m.a.i.n.-.r.o.o.t. .r.o. .r.e.s.u.m.e.=./.d.e.v./.m.a.p.p.e.r./.m.a.i.n.-.s.w.a.p...
Boot0002* Gummiboot	HD(1,800,100000,6eb0c56f-8243-456b-95b6-f042d9b1cad6)File(\EFI\gummiboot\gummibootx64.efi)
Boot0003* UEFI Shell	HD(1,800,100000,6eb0c56f-8243-456b-95b6-f042d9b1cad6)File(\shellx64.efi)
Boot0004* GRUB	HD(1,800,100000,6eb0c56f-8243-456b-95b6-f042d9b1cad6)File(\EFI\arch_grub\grubx64.efi)
Boot0005  Boot Menu
[…]

But:
a) rEFInd does not find your kernel automatically if its name does not end in .efi.
b) I don't know if the selection of the cryptdevice by UUID works already on the kernel command line. I have /dev/sda2, there.
c) More important: Your cryptdevice=/dev/disk/by-uuid/52c6459e-e27a-400f-a282-f73337d70f74:lvm says that the name of the volume group should be lvm, but root=/dev/vgroup-cfr/arch and resume=/dev/vgroup-cfr/swap try to find it under vgroup-cfr. I really think that the name has to be the same – as in my example with cryptdevice=/dev/sda2:main:allow-discards (allow-discards is not important for you, it's just because it's an SSD in my case), root=/dev/mapper/main-root and resume=/dev/mapper/main-swap. In your case, the devices would be /dev/lvm/arch or /dev/mapper/lvm-arch for root and /dev/lvm/swap or /dev/mapper/lvm-swap for swap/resume (or you could change the cryptdevice parameter to cryptdevice=/dev/disk/by-uuid/52c6459e-e27a-400f-a282-f73337d70f74:vgroup-cfr …).

Last edited by HeptaSean (2013-05-29 04:45:25)

WonderWoofy · 2013-05-29 04:56:35

@HeptaSean, this is good info. Thanks.

And BTW, you definitely read the kernel command line much more closely than I did.

Last edited by WonderWoofy (2013-05-29 04:57:06)

cfr · 2013-05-29 23:57:04

HeptaSean wrote:

But:
a) rEFInd does not find your kernel automatically if its name does not end in .efi.

It did not used to but I believe it does now. In any case, I am not relying on automatic scanning.

b) I don't know if the selection of the cryptdevice by UUID works already on the kernel command line. I have /dev/sda2, there.

This does work. Through 3.7.* it worked with rEFInd. It currently works with grub.

c) More important: Your cryptdevice=/dev/disk/by-uuid/52c6459e-e27a-400f-a282-f73337d70f74:lvm says that the name of the volume group should be lvm, but root=/dev/vgroup-cfr/arch and resume=/dev/vgroup-cfr/swap try to find it under vgroup-cfr. I really think that the name has to be the same – as in my example with cryptdevice=/dev/sda2:main:allow-discards (allow-discards is not important for you, it's just because it's an SSD in my case), root=/dev/mapper/main-root and resume=/dev/mapper/main-swap. In your case, the devices would be /dev/lvm/arch or /dev/mapper/lvm-arch for root and /dev/lvm/swap or /dev/mapper/lvm-swap for swap/resume (or you could change the cryptdevice parameter to cryptdevice=/dev/disk/by-uuid/52c6459e-e27a-400f-a282-f73337d70f74:vgroup-cfr …).

Again, this works fine. I could use /dev/mapper/vgroup--cfr-arch, for example.

Unless the EFI stub loader became more particular about this in 3.8.* and 3.9.* than it was prior to that even though it works fine if booted using grub.

lvm is the physical volume name. vgroup-cfr is the name of the volume group. The cryptdevice is sda3. This has uuid 52c6459e-e27a-400f-a282-f73337d70f7 and houses the pv lvm. The volume group is vgroup-cfr. That happens to be on sda3 although it could obviously span other partitions/devices if I had set it up that way. /dev/lvm does not exist. /dev/mapper/lvm is a link to /dev/dm-0 but /dev/mapper/vgroup--cfr-arch (links to /dev/dm-3) is root and /dev/mapper/vgroup--cfr-swap (links to /dev/dm-5) is swap (and so on for the other volumes in the group).

This makes sense I think: it is the LUKS container which is encrypted. LVM sits above LUKS. So the things are logically distinct. One could use LUKS without lvm. In that case, the cryptdevice would exist but the volume group would not (which is labeled vgroup-cfr). What is decrypted at boot is not the volume group. It is the LUKS container. That's why the cryptdevice points to the physical disk partition. Only after the container is decrypted is the volume group available and can the logical volumes be mounted and used. This is why for LVM-on-LUKS, you need the encrypt hook before the lvm2 hook in mkinitcpio.conf.

If the physical volume on your LUKS container has the same label as your volume group, then the names would have to be the same. But their using the same name is coincidental in that case - you are still talking about two logically distinct things where one sits on top of the other. They are not the same thing even if you give them the same name.

If you had more than one physical volume (perhaps because your volume group spanned multiple devices), you would then have more than one encryption container (assuming they were all on top of LUKS) but you would still only have one volume group provided you'd added them all to that group.

Last edited by cfr (2013-05-30 00:16:28)

HeptaSean · 2013-05-30 11:50:57

cfr wrote:

HeptaSean wrote:
a) rEFInd does not find your kernel automatically if its name does not end in .efi.
It did not used to but I believe it does now. In any case, I am not relying on automatic scanning.

Ah, OK. Documentation at http://www.rodsbooks.com/refind/configfile.html#hiding still 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.”

b) I don't know if the selection of the cryptdevice by UUID works already on the kernel command line. I have /dev/sda2, there.
This does work. Through 3.7.* it worked with rEFInd. It currently works with grub.

And, OK again, so, it's a matter of taste, somehow.

This makes sense I think: it is the LUKS container which is encrypted. LVM sits above LUKS. So the things are logically distinct. One could use LUKS without lvm. In that case, the cryptdevice would exist but the volume group would not (which is labeled vgroup-cfr). What is decrypted at boot is not the volume group. It is the LUKS container. That's why the cryptdevice points to the physical disk partition. Only after the container is decrypted is the volume group available and can the logical volumes be mounted and used. This is why for LVM-on-LUKS, you need the encrypt hook before the lvm2 hook in mkinitcpio.conf.

Yes, this makes perfect sense, I stand corrected and thank you for pointing me to understanding this a little better. So, it's pure coincidence (well, kind of intentional coincidence) that the names are the same in my case (only one encrypted physical volume mapped to /dev/mapper/main and a volume group on this physical volume, also named main leading to /dev/mapper/main-root etc.).

Too bad, we are not closer to solving your UEFI problems. I am also out of ideas. Sorry! Still working, here with the above setup.

Last edited by HeptaSean (2013-05-30 11:54:37)

srs5694 · 2013-05-30 14:21:37

schlehmil wrote:

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.

IMHO, yes, it should be reported to Lenovo. I've reported it to Matt Fleming, the author of the EFI stub loader; but as I don't have an affected system, the amount I can do to help is limited. (I do have a Mac that shows similar problems, but I believe the cause is different for it.) Somebody with the problem should probably communicate more directly with Matt Fleming (matt.fleming@intel.com or matt@console-pimps.org).

WonderWoofy wrote:

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?

As the author of rEFInd, I always keep the lowercase "r" when "rEFInd" begins a sentence. This follows the practice of rEFIt -- see, for instance, the very first sentence on the rEFIt Web page.

SNCPlay42 wrote:

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.

It's entirely plausible that there's a sublte timing issue that's the root cause -- perhaps some sort of race condition between EFI hardware access and kernel hardware access.

HeptaSean wrote:

Perhaps, the ext4 driver not working or something.

It's entirely possible that rEFInd's ext4fs driver has bugs; however, those bugs can't be the root source of the problem discussed in this thread, since there have been reports of the problem by people who don't use that driver (gummiboot users, for instance, have the problem; and some rEFInd users say that the problem has disappeared when switching from a TianoCore build of rEFInd to a rEFInd binary built with GNU-EFI, without changing the way the drivers were built).

cfr wrote:

I don't think the ext4 driver can not be working else I assume rEFInd would complain that it could not find the kernel etc. at all rather than apparently trying to start it and failing. I think rEFInd hands off to the kernel fine and whatever goes wrong goes wrong at that point.

I agree with your conclusion; but in theory, if the ext4fs driver were to hang midway through loading the kernel, the result would look a lot like what people are reporting.

re: Dots every other character in EFI boot options list

WonderWoofy wrote:

I am not sure why it does that, but if it looks similar to that then it is right.

I believe that's because text in EFI is almost always stored as UTF-16, which is a two-byte encoding. When encoding something that can be represented in ASCII, every other character will be a NULL, which gets translated to a dot (".") when it's displayed by "efibootmgr -v".

HeptaSean wrote:

WonderWoofy wrote:
I think with a direct efibootmgr entry it needs to be vmlinuz-linux.efi as it is running as an efi application. Gummiboot and rEFInd do this part for you if you don't have it there.
Actually, no, direct efibootmgr entries do not need the .efi extension. This works for me without problems

This may vary from one EFI to another. Also, I'm pretty sure that the EFI shell requires a .efi extension.

HeptaSean wrote:

rEFInd does not find your kernel automatically if its name does not end in .efi.

Actually, this isn't entirely accurate. The default behavior of rEFInd, if it's fed a blank refind.conf file, is to scan only for files that end in .efi; however, the "scan_all_linux_kernels" option in refind.conf causes rEFInd to also scan for files whose names begin with "vmlinuz" or "bzImage". This option has been uncommented by default for quite some time, so with a default installation, kernels will be auto-detected if they're stored using either of these two common names.

cfr · 2013-05-30 21:53:31

I have sent an email to Matt Fleming since the bug seems to be unusually consistent in my case.

I assume the fact that I tested with a direct EFI boot menu entry, avoiding rEFInd altogether, pretty much rules out the ext4 fs driver as the cause?

WonderWoofy · 2013-05-30 22:01:50

cfr wrote:

I have sent an email to Matt Fleming since the bug seems to be unusually consistent in my case.
I assume the fact that I tested with a direct EFI boot menu entry, avoiding rEFInd altogether, pretty much rules out the ext4 fs driver as the cause?

Yes, if you have a copy of the kernel and initramfs in the ESP, and are trying with a direct firmware entry, then there is certainly no use of the ext4fs driver in play there.

I am very interested to know what comes of this. I hope you keep this thread posted.

cfr · 2013-05-31 00:58:55

WonderWoofy wrote:

<OT>
Also, on an unrelated note, all that i915 stuff can be put in /etc/modprobe.d/i915.conf with something like this
% cat /etc/modprobe.d/i915.conf
options i915 lvds_downclock=1 semaphores-1 enable_fbc=1 enable_rc6=-1

Not if I do not want those options for the rescue menu entry. At least, I have been assuming that doing it that way will apply the options to all kernel command lines. But I want a recovery/rescue option with minimal options. Just in case.

I think we have already discussed this in the past, but the rc6 setting is unnecessary, as that is the default.

Yes. I know. But it makes it easy to switch to some other value should I wish to do so.

Also, are you sure you need to use pcie_aspm=force?
</OT>

No. I'm not sure. I can't remember but I do remember adding this in response to something I discovered, even though the details now escape me. But I'm not sure, no. Will having it eat anything if it is not necessary?

WonderWoofy · 2013-05-31 01:55:02

cfr wrote:

Will having it eat anything if it is not necessary?

I don't know... have you lost anything? No but seriously, it shouldn't hurt anything if it is not necessary as it will simply be forcing a setting that is already in place. I was just curious. It apparently has been known on occasion to cause system instability when it is needed apparently. But I guess the trade off for lower power consumption is worth the risk.

dgingrich · 2013-06-05 07:54:07

Just found this thread and wanted to add that I'm having the same problem on a Lenovo Thinkpad T430 (2342-CTO):
* 3.9.2-1; boots
* 3.9.4-1: no boot (blackscreen)

Running gummiboot. Haven't tried any debugging steps yet.

Slab · 2013-06-12 01:29:30

Thanks eumel (#235)!! adding the kernel with efibootmgr works on my laptop too (acer v5-571G). Kernel 3.9.4 from core was working fine with refind and gummiboot. Upgrade to 3.9.5 and i couldn't boot with refind or gummiboot.

Firmware: UEFI 2.31 (Phoenix Technologies Ltd. 4660.22136)

cfr · 2013-06-12 19:04:53

Does *anybody* bar me have this problem *consistently*?

WonderWoofy · 2013-06-12 19:43:00

cfr wrote:

Does *anybody* bar me have this problem *consistently*?

Unfortunately, it sure does sound like you have this worse than anyone else...

Arch Linux

#251 2013-05-27 07:22:54

Re: Kernel 3.7 doesn't boot using EFI Stub

#252 2013-05-27 22:30:09

Re: Kernel 3.7 doesn't boot using EFI Stub

#253 2013-05-28 00:31:14

Re: Kernel 3.7 doesn't boot using EFI Stub

#254 2013-05-28 00:59:09

Re: Kernel 3.7 doesn't boot using EFI Stub

#255 2013-05-28 01:25:15

Re: Kernel 3.7 doesn't boot using EFI Stub

#256 2013-05-28 01:29:44

Re: Kernel 3.7 doesn't boot using EFI Stub

#257 2013-05-28 01:42:32

Re: Kernel 3.7 doesn't boot using EFI Stub

#258 2013-05-28 01:53:59

Re: Kernel 3.7 doesn't boot using EFI Stub

#259 2013-05-28 22:32:42

Re: Kernel 3.7 doesn't boot using EFI Stub

#260 2013-05-28 22:56:29

Re: Kernel 3.7 doesn't boot using EFI Stub

#261 2013-05-29 02:49:35

Re: Kernel 3.7 doesn't boot using EFI Stub

#262 2013-05-29 03:52:59

Re: Kernel 3.7 doesn't boot using EFI Stub

#263 2013-05-29 04:44:16

Re: Kernel 3.7 doesn't boot using EFI Stub

#264 2013-05-29 04:56:35

Re: Kernel 3.7 doesn't boot using EFI Stub

#265 2013-05-29 23:57:04

Re: Kernel 3.7 doesn't boot using EFI Stub

#266 2013-05-30 11:50:57

Re: Kernel 3.7 doesn't boot using EFI Stub

#267 2013-05-30 14:21:37

Re: Kernel 3.7 doesn't boot using EFI Stub

#268 2013-05-30 21:53:31

Re: Kernel 3.7 doesn't boot using EFI Stub

#269 2013-05-30 22:01:50

Re: Kernel 3.7 doesn't boot using EFI Stub

#270 2013-05-31 00:58:55

Re: Kernel 3.7 doesn't boot using EFI Stub

#271 2013-05-31 01:55:02

Re: Kernel 3.7 doesn't boot using EFI Stub

#272 2013-06-05 07:54:07

Re: Kernel 3.7 doesn't boot using EFI Stub

#273 2013-06-12 01:29:30

Re: Kernel 3.7 doesn't boot using EFI Stub

#274 2013-06-12 19:04:53

Re: Kernel 3.7 doesn't boot using EFI Stub

#275 2013-06-12 19:43:00

Re: Kernel 3.7 doesn't boot using EFI Stub

Board footer