Kernel 3.7 doesn't boot using EFI Stub

WonderWoofy · 2013-08-22 23:24:15

Oh mrunion can boot to the multi-user.target? I guess I missed that...

cfr · 2013-08-22 23:28:51

mrunion wrote:

I did find that I can boot to the command line with 3.10.7 and refind, but I can't boot into X. This may make my problem different.

mrunion · 2013-08-22 23:51:09

I found what my particular issue is: nvidia-325.15-3

I rolled back to nvidia 325.15-1 and the machine will boot to X. I will investigate a different solution for my issue. (It may very well be that I have to wait on nVidia!)

ronmon · 2013-08-23 16:08:36

I don't think that the problems with linux-3.10.7 are hardware specific. An upgrade this morning from 3.10.3-1 to 3.10.7-1 left my desktop unbootable. Had to whip out my rescue thumb drive and roll that back as well as refind from 0.7.3-2 to 0.7.1-4 (tried just the kernel first), then re-install nvidia, nvidia-utils and nvidia-libgl to get X working again.

Not my favorite way to start the day.

the.ridikulus.rat · 2013-11-21 09:53:13

https://bugs.archlinux.org/task/33745#comment116633

srs5694 · 2013-11-21 14:33:50

the.ridikulus.rat wrote:

https://bugs.archlinux.org/task/33745#comment116633

That (or using SYSLINUX or some other EFI boot loader) is precisely the workaround that people with this problem have been using for ages.

WonderWoofy · 2013-11-21 14:36:01

srs5694 wrote:

the.ridikulus.rat wrote:
https://bugs.archlinux.org/task/33745#comment116633
That (or using SYSLINUX or some other EFI boot loader) is precisely the workaround that people with this problem have been using for ages.

If you read the comment to that bug report directly above Keshav's there is someone reporting that syslinux efi v6.02 is not working apparently... haven't actually tested this, but if that is the case it explains why Keshav is suggesting grub instead.

the.ridikulus.rat · 2013-11-21 18:17:52

srs5694 wrote:

the.ridikulus.rat wrote:
https://bugs.archlinux.org/task/33745#comment116633
That (or using SYSLINUX or some other EFI boot loader) is precisely the workaround that people with this problem have been using for ages.

Yes, I know that. However many of those users do not know how to make a proper GRUB based UEFI USB drive (especially the config part). That is why I added those instructions to the wiki.

WonderWoofy wrote:

If you read the comment to that bug report directly above Keshav's there is someone reporting that syslinux efi v6.02 is not working apparently... haven't actually tested this, but if that is the case it explains why Keshav is suggesting grub instead.

Actually, there are lot more issue with Syslinux EFI support. It does not support chainloading EFI applications, so it cannot be used in the ISOs yet (since you need chainloader support to launch the included UEFI Shell binaries) and many other EFI related issues (some of them reported by me). Browse the bug reports at http://bugzilla.syslinux.org/ for an idea.

mcloaked · 2014-05-23 09:24:55

srs5694 wrote:

You can learn about your firmware with dmesg:
dmesg | grep -i efi
[    0.000000] efi: EFI v2.00 by American Megatrends
[    0.000000] efi:  ACPI 2.0=0x7bb5df98  SMBIOS=0x7bb88e18 
[    0.000000] efi: mem00: type=3, attr=0xf, range=[0x0000000000000000-0x0000000000048000) (0MB)
[    0.000000] efi: mem01: type=2, attr=0xf, range=[0x0000000000048000-0x0000000000050000) (0MB)
...
[    3.385592] efifb: probing for efifb
[    3.386083] efifb: framebuffer at 0xc0000000, mapped to 0xffffc90011a00000, using 6144k, total 32704k
[    3.386088] efifb: mode is 1024x768x32, linelength=4096, pages=1
[    3.386090] efifb: scrolling: redraw
[    3.386093] efifb: Truecolor: size=8:8:8:8, shift=24:16:8:0
[    3.389666] fb0: EFI VGA frame buffer device
[    3.579290] EFI Variables Facility v0.08 2004-May-17
[   16.494986] fb: conflicting fb hw usage inteldrmfb vs EFI VGA - removing generic driver
I've trimmed over 100 lines of "efi: mem???" lines from this output. Note that "dmesg" displays the kernel ring buffer, which is limited in size and cyclical -- after the system has been up for long enough, the older messages will be removed. Thus, you might get this type of EFI information only shortly after booting. What "shortly" is depends on how many kernel messages get generated -- it could be weeks, or just seconds if a driver is having problems and generating lots of messages.
Although the bug fix to which I linked specifically mentioned Apple firmware, it's entirely plausible that the same bug exists in non-Apple implementations.

I just tried this for my Lenovo Thinkpad S540 with the following output:

$ dmesg | grep -i efi
[    0.000000] efi: EFI v2.31 by Lenovo
[    0.000000] efi:  ACPI=0xccffe000  ACPI 2.0=0xccffe014  SMBIOS=0xcce13000 
[    0.000000] efi: mem00: type=7, attr=0xf, range=[0x0000000000000000-0x0000000000001000) (0MB)
[    0.000000] efi: mem01: type=2, attr=0xf, range=[0x0000000000001000-0x0000000000007000) (0MB)
[    0.000000] efi: mem02: type=7, attr=0xf, range=[0x0000000000007000-0x0000000000058000) (0MB)
[    0.000000] efi: mem03: type=0, attr=0xf, range=[0x0000000000058000-0x0000000000059000) (0MB)
[    0.000000] efi: mem04: type=7, attr=0xf, range=[0x0000000000059000-0x000000000009c000) (0MB)
[    0.000000] efi: mem05: type=0, attr=0xf, range=[0x000000000009c000-0x000000000009d000) (0MB)
[    0.000000] efi: mem06: type=4, attr=0xf, range=[0x000000000009d000-0x000000000009e000) (0MB)
[    0.000000] efi: mem07: type=0, attr=0xf, range=[0x000000000009e000-0x00000000000a0000) (0MB)
[    0.000000] efi: mem08: type=7, attr=0xf, range=[0x0000000000100000-0x0000000001000000) (15MB)
[    0.000000] efi: mem09: type=2, attr=0xf, range=[0x0000000001000000-0x0000000001f5b000) (15MB)
[    0.000000] efi: mem10: type=7, attr=0xf, range=[0x0000000001f5b000-0x000000007faea000) (2011MB)
[    0.000000] efi: mem11: type=2, attr=0xf, range=[0x000000007faea000-0x0000000080000000) (5MB)
[    0.000000] efi: mem12: type=7, attr=0xf, range=[0x0000000080000000-0x00000000baed5000) (942MB)
[    0.000000] efi: mem13: type=4, attr=0xf, range=[0x00000000baed5000-0x00000000baef5000) (0MB)
[    0.000000] efi: mem14: type=7, attr=0xf, range=[0x00000000baef5000-0x00000000bcbbf000) (28MB)
[    0.000000] efi: mem15: type=1, attr=0xf, range=[0x00000000bcbbf000-0x00000000bcf78000) (3MB)
[    0.000000] efi: mem16: type=4, attr=0xf, range=[0x00000000bcf78000-0x00000000bcf8f000) (0MB)
[    0.000000] efi: mem17: type=0, attr=0xf, range=[0x00000000bcf8f000-0x00000000bd191000) (2MB)
[    0.000000] efi: mem18: type=4, attr=0xf, range=[0x00000000bd191000-0x00000000bdec5000) (13MB)
[    0.000000] efi: mem19: type=7, attr=0xf, range=[0x00000000bdec5000-0x00000000bdee3000) (0MB)
[    0.000000] efi: mem20: type=2, attr=0xf, range=[0x00000000bdee3000-0x00000000bdf04000) (0MB)
[    0.000000] efi: mem21: type=7, attr=0xf, range=[0x00000000bdf04000-0x00000000be0d8000) (1MB)
[    0.000000] efi: mem22: type=1, attr=0xf, range=[0x00000000be0d8000-0x00000000be104000) (0MB)                  
[    0.000000] efi: mem23: type=7, attr=0xf, range=[0x00000000be104000-0x00000000bee56000) (13MB)                 
[    0.000000] efi: mem24: type=4, attr=0xf, range=[0x00000000bee56000-0x00000000bf20f000) (3MB)                  
[    0.000000] efi: mem25: type=7, attr=0xf, range=[0x00000000bf20f000-0x00000000bf5c8000) (3MB)                  
[    0.000000] efi: mem26: type=4, attr=0xf, range=[0x00000000bf5c8000-0x00000000bf5d3000) (0MB)                  
[    0.000000] efi: mem27: type=7, attr=0xf, range=[0x00000000bf5d3000-0x00000000bf5f5000) (0MB)                  
[    0.000000] efi: mem28: type=4, attr=0xf, range=[0x00000000bf5f5000-0x00000000bf62f000) (0MB)                  
[    0.000000] efi: mem29: type=7, attr=0xf, range=[0x00000000bf62f000-0x00000000bf634000) (0MB)                  
[    0.000000] efi: mem30: type=4, attr=0xf, range=[0x00000000bf634000-0x00000000bfe5d000) (8MB)                  
[    0.000000] efi: mem31: type=7, attr=0xf, range=[0x00000000bfe5d000-0x00000000bfe5f000) (0MB)                  
[    0.000000] efi: mem32: type=4, attr=0xf, range=[0x00000000bfe5f000-0x00000000bfe62000) (0MB)                  
[    0.000000] efi: mem33: type=7, attr=0xf, range=[0x00000000bfe62000-0x00000000bfe64000) (0MB)
[    0.000000] efi: mem34: type=4, attr=0xf, range=[0x00000000bfe64000-0x00000000bfe78000) (0MB)
[    0.000000] efi: mem35: type=7, attr=0xf, range=[0x00000000bfe78000-0x00000000bfe79000) (0MB)
[    0.000000] efi: mem36: type=4, attr=0xf, range=[0x00000000bfe79000-0x00000000c3104000) (50MB)
[    0.000000] efi: mem37: type=7, attr=0xf, range=[0x00000000c3104000-0x00000000cb83f000) (135MB)
[    0.000000] efi: mem38: type=3, attr=0xf, range=[0x00000000cb83f000-0x00000000cbd04000) (4MB)
[    0.000000] efi: mem39: type=5, attr=0x800000000000000f, range=[0x00000000cbd04000-0x00000000cbf04000) (2MB)
[    0.000000] efi: mem40: type=6, attr=0x800000000000000f, range=[0x00000000cbf04000-0x00000000ccb7f000) (12MB)
[    0.000000] efi: mem41: type=0, attr=0xf, range=[0x00000000ccb7f000-0x00000000ccdc2000) (2MB)
[    0.000000] efi: mem42: type=10, attr=0xf, range=[0x00000000ccdc2000-0x00000000cce12000) (0MB)
[    0.000000] efi: mem43: type=0, attr=0xf, range=[0x00000000cce12000-0x00000000cce7f000) (0MB)
[    0.000000] efi: mem44: type=10, attr=0xf, range=[0x00000000cce7f000-0x00000000ccf7f000) (1MB)
[    0.000000] efi: mem45: type=9, attr=0xf, range=[0x00000000ccf7f000-0x00000000ccfff000) (0MB)
[    0.000000] efi: mem46: type=4, attr=0xf, range=[0x00000000ccfff000-0x00000000cd000000) (0MB)
[    0.000000] efi: mem47: type=7, attr=0xf, range=[0x0000000100000000-0x000000022f600000) (4854MB)
[    0.000000] efi: mem48: type=0, attr=0x0, range=[0x00000000000a0000-0x00000000000c0000) (0MB)
[    0.000000] efi: mem49: type=0, attr=0x0, range=[0x00000000cd000000-0x00000000cfa00000) (42MB)
[    0.000000] efi: mem50: type=11, attr=0x8000000000000001, range=[0x00000000f80f8000-0x00000000f80f9000) (0MB)
[    0.000000] efi: mem51: type=0, attr=0x0, range=[0x00000000fe101000-0x00000000fe113000) (0MB)
[    0.000000] efi: mem52: type=11, attr=0x8000000000000001, range=[0x00000000fed1c000-0x00000000fed20000) (0MB)
[    0.000000] efi: mem53: type=0, attr=0x0, range=[0x0000000000000000-0x0000000000000000) (0MB)
[    0.000000] efi: mem54: type=0, attr=0x0, range=[0x0000000000000000-0x0000000000000000) (0MB)
[    0.000000] efi: mem55: type=0, attr=0x0, range=[0x0000000000000000-0x0000000000000000) (0MB)
[    0.000000] efi: mem56: type=0, attr=0x0, range=[0x0000000000000000-0x0000000000000000) (0MB)
[    0.000000] ACPI: UEFI 00000000ccfdf000 000042 (v01 LENOVO TP-GP    00001550 PTEC 00000002)
[    0.000000] ACPI: UEFI 00000000ccfdb000 0002E2 (v01 LENOVO TP-GP    00001550 PTEC 00000002)
[    1.046323] efifb: probing for efifb
[    1.048026] efifb: framebuffer at 0xe0000000, mapped to 0xffffc90004f00000, using 8100k, total 8100k
[    1.048028] efifb: mode is 1920x1080x32, linelength=7680, pages=1
[    1.048029] efifb: scrolling: redraw
[    1.048031] efifb: Truecolor: size=8:8:8:8, shift=24:16:8:0
[    1.059811] fb0: EFI VGA frame buffer device
[    1.126350] fb: conflicting fb hw usage inteldrmfb vs EFI VGA - removing generic driver
[    2.028085] tsc: Refined TSC clocksource calibration: 2394.456 MHz
[    2.733896] [Firmware Bug]: ACPI(PEGP) defines _DOD but not _DOS

This system is booted with the current 0.7.9 version of rEFInd in arch, without an apparent problem, but what I don't know is whether the last few lines of the output above indicate that there are still issues with the efi firmware but somehow the system is lucky to have booted, and may fail to boot with a future updated kernel?

In this laptop the BIOS was updated a week or so back when Lenovo released version 1.55 for this machine.

I would be interested if srs5694 could comment on this or if there is any recent news about this?

mcloaked · 2014-05-25 20:17:10

If anyone has the efistub problem booting particular kernels and wants to have grub as an alternative to boot the same kernels, but without using efistub, as a fallback then it might be a help looking at my thread at https://bbs.archlinux.org/viewtopic.php … 3#p1419053 which details how I got grub-standalone working chainloaded from rEFInd. I used this approach to avoid having the normal method of installing grub which automatically tries to write boot entries into the NVRAM but I only wanted to have rEFInd entries as the normal boot options, and have grub completely separated from the normal boot manager but still available as a fallback in the event that a particular kernel won't boot. But it is valuable knowing that I can simply boot the same kernel using grub instead, either as a submenu of a normal rEFInd entry or an icon within rEFInd that will boot grub as a separate item in the rEFInd graphical screen, without having to resort to booting a rescue disk.

Another thought I had which just possibly may be worth pursuing is to find whether the BIOS on machines afflicted by the efistub boot fail issue are written by a common source. I believe that at least some of the Thinkpads which have this problem may have BIOS firmware that was originally written by Phoenix. It might be interesting to know if there are any machines that have this problem have BIOS firmware written by a different company? If this is not relevant please respond, but if it is a possible haystack in which to search for the needle of the faulty code would be useful to know.

Last edited by mcloaked (2014-05-25 20:17:59)

dhave · 2014-05-25 23:36:12

I read your thread here: http://sourceforge.net/p/refind/discuss … c79a/#b631

Are you saying that this annoying bootstub problem is fixed with rEFInd 0.8.1? Or in this thread are you talking only about partuuid volume designation?

It's probably clear to others, but I had trouble sorting it out. Thanks.

mcloaked · 2014-05-26 08:15:48

dhave wrote:

I read your thread here: http://sourceforge.net/p/refind/discuss … c79a/#b631
Are you saying that this annoying bootstub problem is fixed with rEFInd 0.8.1? Or in this thread are you talking only about partuuid volume designation?
It's probably clear to others, but I had trouble sorting it out. Thanks.

In the thread you quote it is related to the use of additional tokens for the volume line which were implemented from rEFInd version 0.8.0 onwards. So prior to that you could refer to a partition in a manual rEFInd stanza containing the kernel and initrd by using the filesystem label or the filesystem number, but not using the uuid or partuuid. Rod Smith added those as available tokens in version 0.8.0

The efistub problem needs more testing before knowing if it is fixed or not but since using rEFInd version 0.8.1 from Rod Smith's gnu-efi compiled package on the rEFInd upstream web site I have not had any problem booting arch kernels on my machine. I know of one other user who has a different Thinkpad to me, and who compiles the latest rc kernels and who could not boot 3.15 rc6 using the stock arch rEFInd version 0.7.9, but using Rod Smith's gnu-efi rEFInd version 0.8.1 is now able to boot that kernel. So it will depend on a range of arch users to test booting on their various machines using the newer versions of rEFInd to know if the problem still persists and also on which specific machines using which specific version of rEFInd for current and newer kernels. The threads have been relatively quiet recently, so it is not clear if this is because people have moved to using Rod Smith's alternative compiled version of rEFInd, or if people have switched to booting using alternative bootloaders such as grub to avoid the issue. So it is still not clear if the problem has gone away or not.

It would also be important to see what happens when the arch refind-efi package is updated to the current upstream version, since there have been a number of fixes since the version in the arch repos went out of date. It is possible that how it is compiled may also have an impact. For example the tianocore library used to compile the package is the 2010 version both in arch and in the upstream compiled binary. I don't know if anyone has compiled it used the 2014 tianocore library and tested it yet but that would be a useful additional datum point.

Last edited by mcloaked (2014-05-26 08:16:42)

GeneArch · 2014-06-01 14:29:41

Just wanted to share that I have experienced the UEFI boot problem on my lenovo W540 for quite some time.

Today, for the first time, my Asus server showed the same problem - refind hangs when trying to boot arch stock kernel (3.14.5) but luckily worked fine on mu custom built 3.15-rc7 kernel. Since arch refind (0.8.1) is now built with gnuefi instead of tianacore there is one fewer fall back tools available

My server is built from :

Manufacturer: ASUSTeK COMPUTER INC.
Product Name: MAXIMUS VI HERO
BIOS Information
Vendor: American Megatrends Inc.
Version: 1102
Release Date: 11/21/2013

Does anyone understand what the underlying problem is?
And since refind (and gummiboot and ... ) is not reliable way to boot - is there anything else that is reliable?

thanks

gene

mcloaked · 2014-06-01 18:04:04

Using grub as a fallback should be reliable as it does not use the efistub and as far as the evidence goes the boot problem is only seen when using the kernel efistub to boot. But this information in the previous post about a non-Lenovo machine suffering the same issue would be usefully added to the long running arch bug at https://bugs.archlinux.org/task/33745?project=1

It would also be possibly useful to know if the BIOS firmware for the Maximus Vi Hero board has any common efi code with that written by Phoenix since that is the code base behind the Thinkpad BIOS firmware. That is a possible link?

Last edited by mcloaked (2014-06-02 21:09:03)

mcloaked · 2014-07-18 15:43:22

I have a question that I would appreciate knowing the answer to concerning the patch that was suggested by Thomas Bachler in the long running bug report at https://bugs.archlinux.org/task/33745#comment125222

The patch referred to is https://git.kernel.org/cgit/linux/kerne … 63c26a0505 and this refers to arch/x86 - but my question is whether although this "appears" to be concerned with 32 bit, does this patch then apply to both x86_64 as well as i386 kernels? I have to admit a hole in my knowledge here which I hope that more expert users than I am will be able to fill with their expertise?

This patch is in the current [core] kernel, and I had presumed would be in 3.15.5-2-ARCH x86_64 but then I have not had any problems with efi stub loader boot for quite some time. So now I was unsure if I was lucky not having the efi stub loader problem or whether the patch will fix it for people using both x86_64 and i386.

Can someone enlighten me on this?

Thanks in advance.

Edit: I guess that this code gets pulled in for both 32 and 64 bit kernel builds so maybe this answers the question!

Last edited by mcloaked (2014-07-19 19:22:38)

carbohydrates · 2015-06-28 05:41:09

I was very happy when I first got EFISTUB working on my laptop. It took a ton of fruitless of research and eventually even more trial and error to get working...but when I did figure it out, I got my computer booting in under 3 seconds.

This bug ruined that. It just stopped working one day, and nobody every fixed it. It's just impossible to boot via EFISTUB on my laptop now. All the alternatives or workarounds are inferior. I'm trying to upt up with using Grub right now, but it's crap compard to EFISTUB.

I'm sad to see this still hasn't been corrected. Somebody broke it. And it's still broken...

edit: And additionally, I stopped being able to boot any UEFI installation media since around the same time. Workarounds are difficult/complex enough that I haven't managed to get it working again since. I've been forced to repair my UEFI system with a BIOS install drive ever since. If I ever have to install Arch from scratch again, I will be forced to install as a BIOS system instead of UEFI. It's unfortunate, I really prefer EFI...

Last edited by carbohydrates (2015-06-28 05:47:16)

jasonwryan · 2015-06-28 06:19:45

Please don't necrobump. Arch has moved on, so should you: https://wiki.archlinux.org/index.php/Fo … bumping.22

Closing

Arch Linux

#326 2013-08-22 23:24:15

Re: Kernel 3.7 doesn't boot using EFI Stub

#327 2013-08-22 23:28:51

Re: Kernel 3.7 doesn't boot using EFI Stub

#328 2013-08-22 23:51:09

Re: Kernel 3.7 doesn't boot using EFI Stub

#329 2013-08-23 16:08:36

Re: Kernel 3.7 doesn't boot using EFI Stub

#330 2013-11-21 09:53:13

Re: Kernel 3.7 doesn't boot using EFI Stub

#331 2013-11-21 14:33:50

Re: Kernel 3.7 doesn't boot using EFI Stub

#332 2013-11-21 14:36:01

Re: Kernel 3.7 doesn't boot using EFI Stub

#333 2013-11-21 18:17:52

Re: Kernel 3.7 doesn't boot using EFI Stub

#334 2014-05-23 09:24:55

Re: Kernel 3.7 doesn't boot using EFI Stub

#335 2014-05-25 20:17:10

Re: Kernel 3.7 doesn't boot using EFI Stub

#336 2014-05-25 23:36:12

Re: Kernel 3.7 doesn't boot using EFI Stub

#337 2014-05-26 08:15:48

Re: Kernel 3.7 doesn't boot using EFI Stub

#338 2014-06-01 14:29:41

Re: Kernel 3.7 doesn't boot using EFI Stub

#339 2014-06-01 18:04:04

Re: Kernel 3.7 doesn't boot using EFI Stub

#340 2014-07-18 15:43:22

Re: Kernel 3.7 doesn't boot using EFI Stub

#341 2015-06-28 05:41:09

Re: Kernel 3.7 doesn't boot using EFI Stub

#342 2015-06-28 06:19:45

Re: Kernel 3.7 doesn't boot using EFI Stub

Board footer