Kernel 3.7 doesn't boot using EFI Stub

WonderWoofy · 2013-03-24 23:50:42

Update to my issues...

dhave wrote:

Thanks for the diagnosis. If you're right, then I guess we need to wait for a firmware update for our machines, right?

This seemed to have solved my issues... I think.

cfr · 2013-03-25 03:42:48

Could you clarify? Do you mean a firmware update solved things?

You are correct about my practical objection to gummiboot taking the default location. This is complex but I must have the most reliable boot loader/manager in that spot so that when I wipe all EFI entries to restore bluetooth, I can still boot. Right now, that means grub needs that location. Anything which might overwrite that is not going to be permitted on my machine. Period.

Theoretically, though, I object on principled grounds. It is not up to gummiboot to decide it thinks it should be my fallback. That's like firefox making itself the default web browser every time it updates without asking permission. (Note: I know ff doesn't - it asks. That's my point.) But it is worse because ff is just software and it is easy to start another browser. gummiboot is not in that position. In my view, it is just like Windows doing this with its own boot loader. (Note: I hear it does this - I don't know as I don't use it. At least, I do a little when forced to but I have no idea how it boots. Probably not EFI on university machines, though.)

Until the 3.8.* kernels, rEFInd was also perfectly reliable for me but not any longer .

WonderWoofy · 2013-03-25 04:07:51

I just updated my bios, yes. I realized that my new motherboard shipped with 2.08 (I think it was anyway) and there was a 2.50 available. So now that I have a reliable wireless card with the right FRU, I don't need a modified bios and can update the bios as I please.

I have not tested this extensively though, and cannot say whether this was just a two time (so far) fluke or not. But I have changed the default kernel to the official Arch kernel so that I can test it (and make use of systemd user sessions for a while).

If I were you, I would test gummiboot anyway. I think just seeing if an efibootmgr entry would actually start gummiboot on your finicky machine would be worth the time. Then if it does work, just make sure you have a configuration in gummiboot to get to the reliable boot method you know works (in this case grub).

Thump · 2013-03-25 12:23:32

Hi. I'm from Gentoo world.

lobo2 wrote:

lobo2 wrote:
thinkpad t530 doesn't boot with kernel 3.7.9.2 work fine with 3.8.2.1 from testing
3.8.3-2 killed it.

unikum wrote:

I use gumiiboot. With 3.8.3-2 not boot (gummiboot menu appears, when choose Arch linux - black screen). 3.8.2-1 - OK.

cfr wrote:

I can reproduce this (if it is the same bug which srs5694 seems to think it is). I was not affected with any of the previous kernels.
My details at https://bbs.archlinux.org/viewtopic.php … 6#p1245916

I've faced the same issue on HP Compaq Presario CQ58 starting from 3.8.3, 3.8.2 is fine. 3.8.4 is broken for me too.
3.8.3 brought a lot of changes in EFI.
I'm not using any bootloaders, so I think the issue is in upstream.
Here is the Bug 462705 - https://bugs.gentoo.org/show_bug.cgi?id=462705 for Gentoo if you're interested.

The only option I see for us is to compile vanilla sources 3.8.2 and 3.8.3 with debugging, investigate it in virtual machine and post a bugreport in kernel development. I'm not sure that I can take this job.

This upstream Bug 55471 - https://bugzilla.kernel.org/show_bug.cgi?id=55471 can be related to the issue.

Of course, bugs with rEFInd/TianoCore and kernel issue shouldn't be mixed.

Last edited by Thump (2013-03-25 12:30:21)

srs5694 · 2013-03-25 16:46:04

cfr wrote:

srs5694 wrote:
I'm definitely interested to hear if the new rEFInd binary works for others, too. Here's the link:
http://www.rodsbooks.com/refind_x64_gnuefi_3.6.8.efi
Will this work OK with the fs drivers etc. from the version in the official repos or do I need to get those from the official 3.6.8 release?

Yes, the GNU-EFI version should work with filesystem drivers from the TianoCore-built Arch package. How it works is that rEFInd (whether built with TianoCore or GNU-EFI) scans for drivers and loads them, using the same system calls that launch boot loaders. Thus, it's ultimately the EFI that runs the drivers; rEFInd just tells it to do so.

Thump · 2013-03-25 19:34:13

lobo2 wrote:

3.8.3-2 killed it.

unikum wrote:

I use gumiiboot. With 3.8.3-2 not boot (gummiboot menu appears, when choose Arch linux - black screen). 3.8.2-1 - OK.

cfr wrote:

I can reproduce this (if it is the same bug which srs5694 seems to think it is). I was not affected with any of the previous kernels.

If you're experiencing an issue with EFI support since 3.8.3 and it was working in 3.8.2 you can go to Bug 55471 - https://bugzilla.kernel.org/show_bug.cgi?id=55471 and download a working patch.
Or you should wait 3.8.5, but I'm not sure if patch will be included there.

cfr · 2013-03-25 23:33:57

Thump wrote:

lobo2 wrote:
3.8.3-2 killed it.
unikum wrote:
I use gumiiboot. With 3.8.3-2 not boot (gummiboot menu appears, when choose Arch linux - black screen). 3.8.2-1 - OK.
cfr wrote:
I can reproduce this (if it is the same bug which srs5694 seems to think it is). I was not affected with any of the previous kernels.
If you're experiencing an issue with EFI support since 3.8.3 and it was working in 3.8.2 you can go to Bug 55471 - https://bugzilla.kernel.org/show_bug.cgi?id=55471 and download a working patch.
Or you should wait 3.8.5, but I'm not sure if patch will be included there.

Thanks but that's not the problem I'm seeing. I can't boot the kernels using the EFI STUB stuff. It has nothing to do with setting an EFI boot manager entry.

forumache · 2013-03-26 11:52:52

Something even stranger here:

Boot via EFI STUB with firmware entry created by efibootmgr: Perfect!
Boot UEFI Shell then run archlinux.nsh (a script to launch Arch as indicated on WIKI): Works!
Gummiboot: I select Arch Entry and Arch boots. Great!

Next step: Since I have Gummiboot installed, let's get rid of efibootmgr created entry, I will boot via gummiboot.

Results:
Boot via EFI STUB from firmware: not possible since I deleted the entry
Boot UEFI Shell then run archlinux.nsh: Works!
Gummiboot: I select Arch Entry and I get... wait for it ... BLACK SCREEN.

Arch upgraded to latest (no "testing" bits).

I guess since my EFI STUB works via firmware and I also have archlinux.nsh to run manually in case when upgrading the firmware I lose NVRAM variables for proper boot of EFISTUB (it happened), I will remove gummiboot since I cannot make it work alone. Strange, I know, and I have no clue. Someone? Anyone?

dhave · 2013-03-26 15:29:09

FWIW, Arch kernel 3.8.4-1 boots fine for me directly from the UEFI shell using the simple archlinux.nsh script on the UEFI Bootloaders wiki page.

It's an awkward way to boot into Arch (and, for now, I'm opting instead to boot via Grub2) but at least it works.

Last edited by dhave (2013-03-26 15:33:54)

WonderWoofy · 2013-03-26 20:57:14

dhave wrote:

FWIW, Arch kernel 3.8.4-1 boots fine for me directly from the UEFI shell using the simple archlinux.nsh script on the UEFI Bootloaders wiki page.
It's an awkward way to boot into Arch (and, for now, I'm opting instead to boot via Grub2) but at least it works.

I have found that personally the most reliable way to boot, while still using the efistub is by using an efibootmgr entry directly. So I use this:

# efibootmgr -c -d /dev/sda -p 1 -L "Arch Linux" -l '\EFI\arch\vmlinuz-linux.efi' -u "root=/dev/mapper/volgrp0-root_arch add_efi_memmap initrd=\\EFI\\arch\\initramfs-linux.img quiet"

As a side note, having more to do with LVM probably: I am not sure if it is just pure dumb luck or a placebo or whatever, but since I have removed "libahci.ignore_sss=1" I have a more reliable boot. I have a laptop with three drives, one of which is in a cheap Chinese optical caddy. Quite a lot of the time, when my volume group cannot be found, it fails to find this second drive that is in the optical bay. Apparently the small SATA power supply that it takes and converts only provides 5 V instead of 3.3 V, 5 V, and 12 V. So I am currently theorizing that having all the SSDs "spin up" at once is not getting enough power to it... though I have not a shred of evidence to back that up.

Stitch · 2013-03-27 06:59:46

My systems got broken when I upgraded from 3.8.3 to 3.8.4. All of them.
I tested on a Dell laptop XPS14 and on a blade server PowerEdge M620. None of them work.
Gummiboot does not work - black screen
Creating boot entries directly with efibootmgr does not work - same black screen.

Nothing new here. Just reporting for the sake of statistics.

donniezazen · 2013-03-27 08:22:31

I just did a clean install with stock refind-efi 0.6.8-1 and linux-3.8.4-1. My system boots fine no hangs or anything.

dr.dynamics · 2013-03-27 18:13:06

Updated my firmware, ASRock H67M-ITX from 1.3 to 2.1 and now standard refind will boot kernel 3.8.4. It did lose the efibootmgr settings in the process though, so had to add the refind entry back in by boot from USB, and command line, so caution.

dhave · 2013-03-29 21:28:14

dr.dynamics wrote:

Updated my firmware, ASRock H67M-ITX from 1.3 to 2.1 and now standard refind will boot kernel 3.8.4. It did lose the efibootmgr settings in the process though, so had to add the refind entry back in by boot from USB, and command line, so caution.

Has anyone had similar success due to a firmware update in a Thinkpad? I think I'm running UEFI v. 1.44 on my Thinkpad T420. That's update was release on March 3, 2013, but I don't believe it addressed whatever is causing the problem with rEFInd.

dhave · 2013-04-01 15:44:30

I actually think things are working as they should under kernel 3.8.4. I had started getting an unrelated glitch (a systemd target-not-found error) which I mistakenly associated with my attempts to boot via EFI using rEFInd.

So kernel 3.8.4 is in the YES column for me.

FWIW, the systemd error, which sent the system into rescue mode, was resolved by creating symlinks according to instructions on this page, to wit:

"It is a good idea to make this an alias for (i.e. symlink to) multi-user.target (for runlevel 2) or graphical.target (the others)."

The systemd .target files are located in /usr/lib/systemd/system/.

Last edited by dhave (2013-04-01 15:54:10)

donniezazen · 2013-04-01 16:06:17

Where are UEFI tools stored? I found the drivers but can't find shell, etc.

Last edited by donniezazen (2013-04-01 16:06:39)

blackout23 · 2013-04-01 17:16:14

donniezazen wrote:

Where are UEFI tools stored? I found the drivers but can't find shell, etc.

https://wiki.archlinux.org/index.php/UE … load_links

There you go! I renamed mine to shellx64.efi

v2Beta works great.

Last edited by blackout23 (2013-04-01 17:17:39)

donniezazen · 2013-04-01 18:13:46

@blackout23 Thanks.

Stitch · 2013-04-04 04:14:34

Now the new live CD 13.04 does not even boot. At least none of the Dell machines can boot from it. Not laptops, not servers ...
All same - black screen after the initial EFI Shell menu display.

catharsis · 2013-04-05 12:51:08

dhave wrote:

So kernel 3.8.4 is in the YES column for me.

Same here, 3.8.4 has been working flawlessly for me. Has anyone been brave enough to try 3.8.5 out yet?

mrunion · 2013-04-05 23:13:15

3.8.5 Works for me as well.

dhave · 2013-04-06 00:16:44

mrunion wrote:

3.8.5 Works for me as well.

+1

cfr · 2013-04-06 01:18:49

Doesn't work for me. Nothing 3.8.* has worked for me. Still using grub...

cfr · 2013-04-06 03:12:01

Question: Should the Beginners' Guide be altered either to recommend something more reliable than the rEFInd/EFI STUB combination or to at least warn users that if it does not work, they should try an alternative method such as GRUB?

I've seen a number of threads from new users who are to varying degrees at a loss because they have (or think they have) followed the instructions and yet cannot boot. A reasonable number of them *do* seem to have followed the instructions and yet cannot boot because of this bug.

I guess I think that the recommendation in the Beginners' Guide should be a reasonably reliable one if at all possible. rEFInd is great when it works but right now the bugs with this mean it doesn't work - or doesn't work reliably - for significant numbers of users. (Note: I'm not saying the bugs are in rEFInd - I'm just using that as short hand for the various combinations of firmware + rEFInd + kernel etc.)

I think if I was installing for the first time, I would prefer to receive a recommendation for GRUB than rEFInd for EFI booting. That is, I'd rather have clear instructions for a slightly more complicated option which was more likely to work. (And it is not really that complicated - especially if people copy the efi to the fallback loader location if they don't use Windows.)

mcloaked · 2013-04-06 07:55:35

cfr wrote:

Question: Should the Beginners' Guide be altered either to recommend something more reliable than the rEFInd/EFI STUB combination or to at least warn users that if it does not work, they should try an alternative method such as GRUB?
I've seen a number of threads from new users who are to varying degrees at a loss because they have (or think they have) followed the instructions and yet cannot boot. A reasonable number of them *do* seem to have followed the instructions and yet cannot boot because of this bug.
I guess I think that the recommendation in the Beginners' Guide should be a reasonably reliable one if at all possible. rEFInd is great when it works but right now the bugs with this mean it doesn't work - or doesn't work reliably - for significant numbers of users. (Note: I'm not saying the bugs are in rEFInd - I'm just using that as short hand for the various combinations of firmware + rEFInd + kernel etc.)
I think if I was installing for the first time, I would prefer to receive a recommendation for GRUB than rEFInd for EFI booting. That is, I'd rather have clear instructions for a slightly more complicated option which was more likely to work. (And it is not really that complicated - especially if people copy the efi to the fallback loader location if they don't use Windows.)

I have been using rEFInd without any problems - but initially I did not understand how to install the various parts - the better option would be to have really clear and explicit guidance on getting rEFInd installed in the beginners guide - including the potential problems with efibootmgr and using the uefi shell as an alternative to write NVRAM entries. If I get some time I might try to write some wiki advice for rEFInd. I think a clean up of the guidance would be better than simply advising another alternative bootloader?

Arch Linux

#151 2013-03-24 23:50:42

Re: Kernel 3.7 doesn't boot using EFI Stub

#152 2013-03-25 03:42:48

Re: Kernel 3.7 doesn't boot using EFI Stub

#153 2013-03-25 04:07:51

Re: Kernel 3.7 doesn't boot using EFI Stub

#154 2013-03-25 12:23:32

Re: Kernel 3.7 doesn't boot using EFI Stub

#155 2013-03-25 16:46:04

Re: Kernel 3.7 doesn't boot using EFI Stub

#156 2013-03-25 19:34:13

Re: Kernel 3.7 doesn't boot using EFI Stub

#157 2013-03-25 23:33:57

Re: Kernel 3.7 doesn't boot using EFI Stub

#158 2013-03-26 11:52:52

Re: Kernel 3.7 doesn't boot using EFI Stub

#159 2013-03-26 15:29:09

Re: Kernel 3.7 doesn't boot using EFI Stub

#160 2013-03-26 20:57:14

Re: Kernel 3.7 doesn't boot using EFI Stub

#161 2013-03-27 06:59:46

Re: Kernel 3.7 doesn't boot using EFI Stub

#162 2013-03-27 08:22:31

Re: Kernel 3.7 doesn't boot using EFI Stub

#163 2013-03-27 18:13:06

Re: Kernel 3.7 doesn't boot using EFI Stub

#164 2013-03-29 21:28:14

Re: Kernel 3.7 doesn't boot using EFI Stub

#165 2013-04-01 15:44:30

Re: Kernel 3.7 doesn't boot using EFI Stub

#166 2013-04-01 16:06:17

Re: Kernel 3.7 doesn't boot using EFI Stub

#167 2013-04-01 17:16:14

Re: Kernel 3.7 doesn't boot using EFI Stub

#168 2013-04-01 18:13:46

Re: Kernel 3.7 doesn't boot using EFI Stub

#169 2013-04-04 04:14:34

Re: Kernel 3.7 doesn't boot using EFI Stub

#170 2013-04-05 12:51:08

Re: Kernel 3.7 doesn't boot using EFI Stub

#171 2013-04-05 23:13:15

Re: Kernel 3.7 doesn't boot using EFI Stub

#172 2013-04-06 00:16:44

Re: Kernel 3.7 doesn't boot using EFI Stub

#173 2013-04-06 01:18:49

Re: Kernel 3.7 doesn't boot using EFI Stub

#174 2013-04-06 03:12:01

Re: Kernel 3.7 doesn't boot using EFI Stub

#175 2013-04-06 07:55:35

Re: Kernel 3.7 doesn't boot using EFI Stub

Board footer