Kernel 3.7 doesn't boot using EFI Stub

cfr · 2013-06-12 21:05:22

Well, it isn't like grub has failed me yet so things could definitely be worse. I still get to grub from rEFInd because I live in hope that one day, EFI stub will work once more... I just find it weird that it worked and worked and now fails and fails whereas it seems so random for other people but maybe it is because my version of UEFI is so much earlier... Maybe the stub loader now assumes things which don't work with older versions?

WonderWoofy · 2013-06-12 21:12:25

I looked on the Lenovo site, and it appears as though there was a bios update for your machine March 17th. Have you been updating that bios of yours?

cfr · 2013-06-12 21:17:54

Yes, I've been updating the BIOS. The last time I did it was right after Easter as I got the new motherboard and it came with an older BIOS (which Lenovo hadn't configured properly though they implausibly claimed updating the BIOS caused it to complain every boot). Anyway, if that's the latest, I think that's what I've got. (1.18, I believe.) But it does not seem to update the version of UEFI.

WonderWoofy · 2013-06-12 21:19:33

That is indeed frusturating...

Slab · 2013-06-15 14:46:28

Update. The eumel solution works, but if i power on my laptop after being off for a few hours the kernel doesn't boot. i got to restart again and then it boots normally. I'm using gummiboot.

cfr · 2013-06-19 22:20:17

Update: So I have heard back from Matt Flemming who wants me to experiment some. I've told him I will do this as soon as I can but don't expect news fast since I have to learn to compile a kernel which I've never done and I don't have a great deal of time right now. But hopefully once I get some time, I'll figure it through and then hopefully this will help with diagnostics.

cfr · 2013-06-27 22:22:05

Update: I have reproduced the issue with an unpatched kernel compiled from Linus' git repo i.e. this will not boot using EFI stub but will boot with grub. I am now waiting for further instructions from Matt Flemming.

srs5694 · 2013-07-03 00:51:15

Have any of you tried this with the new 3.10.0 kernel that was recently released? (I'm not even sure if an Arch binary package is available yet.) This version works on my Mac Mini, which consistently failed with 3.7.x through 3.9.x kernels -- but given the consistency of my own failures, I doubt if what I was experiencing had the same cause as the bulk of the people in this thread are reporting. Still, it's possible that 3.10.0 will fix this problem....

cfr · 2013-07-03 00:55:24

I reproduced it with 3.10.rc7.8.gacdb37c from upstream. Currently working on the next test...

WonderWoofy · 2013-07-03 01:10:23

@srs5694, there is a 3.10 kernel in [staging] right now. It is waiting for the all the packages with extra modules to be able to build against the new version.

See here: http://www.mail-archive.com/arch-dev-pu … 21573.html

cfr · 2013-07-03 02:47:55

For those watching at home: I think I just established that my machine does get to the decompressed kernel code using refind + stub as well as using grub. (Basically a test kernel reboots the machine either way.)

Last edited by cfr (2013-07-03 02:48:20)

WonderWoofy · 2013-07-03 03:05:10

Home spectator here: So what does this mean in terms of debugging the situation? I take it this means that the bootloader/boot manager can be ruled out as a suspect.

cfr · 2013-07-03 03:10:53

I'm not sure but I think so, yes because it shows that the kernel code is getting run. So the boot manager can't be at fault because it has handed over entirely to the kernel code at this point i.e. the stub loader. At least, I think that is what it means but this is somewhat above my head. So I guess it has to be in the kernel code because it has to be that something goes wrong after that process starts. But I don't really understand it because it is not clear to me why it works when there is a boot loader like grub involved. Except I guess that it doesn't then use the stub loader, is that right?

cfr · 2013-07-06 00:47:30

For those watching at home: I just ran a series of compiles with a patch I was sent. Basically, patch, compile, test; remove first reboot instruction; patch, compile test; remove second reboot; etc. until failure. 7 instructions in the file. Deleting 2 made no difference. Deleting number 3 prevented reboot. So I hope this is helping to narrow down the problem a little. At least, I hope it is helping to narrow down one of the problems a bit. I guess it is rather unlikely that all of the inconsistent issues have the same cause as my extremely consistent one, but who knows?

cfr · 2013-07-09 02:15:47

For interested observers: I just compiled a patched version of the kernel which successfully booted my machine .

WonderWoofy · 2013-07-09 02:18:08

Thats pretty neato! Briefly, how did you get to that point? Did you continuously remove commits sequentially, or have you been getting patches from the developers to try and apply?

cfr · 2013-07-09 02:55:13

Patches from the developer inserting a function to reboot at various points. Remove sequentially until reboot fails. Get another patch. Do the same. I guess that narrowed it down enough for him to send me a patch which he hoped would work. It didn't but the second move which removed a setup_efi_pci() call as well did work. I don't know if it is good or bad that I needed to comment that line to get it to boot.

Last edited by cfr (2013-07-09 02:56:02)

WonderWoofy · 2013-07-09 04:27:57

Interesting... so you have been particularly busy compiling the kernel over and over again! Its certainly for a good cause though, as any increased stability to efistub is welcome in my eyes.

cfr · 2013-07-10 01:18:37

Yes. I have compiled a number of kernels...

Actually, I just compiled another patched one but unfortunately my machine hangs so I guess the fix is not quite there yet. I assume the issue now is to figure out which bit of the setup call causes the hang and I guess it is not memory remapping...

WonderWoofy · 2013-07-10 02:33:53

Well, I think the expectation is that once a working configuration is found, you would then need to test to determine what exactly is causing the breakage/fix. So it would seem logical that you would not just simply stop at soon as the machine boots.

cfr · 2013-07-10 22:28:53

Sure. It is just disappointing because the developer seemed reasonably confident this patch would work. (And the patch was designed to test whether one or other or both bits of memory remapping were problematic by outputting to dmesg.)

Last edited by cfr (2013-07-10 22:29:16)

adn770 · 2013-07-18 15:37:27

Hello

I'm new in Arch linux but I'm already an experienced developer and linux user. I'm facing an strange issue which seems to be related to the topic of this thread.
I've installed arch linux on a macbook 5,1 triple boot (OSX,Linux,Win7) with rEFInd installed from OSX. With the ext4 module and booting using kernel autoscan on /boot (linux rootfs at sda3).

At least the following kernels boot properly in the laptop:

Linux version 3.9.4-1-ARCH (tobias@T-POWA-LX) (gcc version 4.8.0 20130502 (prerelease) (GCC) ) #1 SMP PREEMPT Sat May 25 16:14:55 CEST 2013
Linux version 3.9.8-1-ARCH (tobias@T-POWA-LX) (gcc version 4.8.1 (GCC) ) #1 SMP PREEMPT Thu Jun 27 21:37:31 CEST 2013
Linux version 3.9.9-1-ARCH (tobias@T-POWA-LX) (gcc version 4.8.1 (GCC) ) #1 SMP PREEMPT Wed Jul 3 22:45:16 CEST 2013
Linux version 3.10.1-1-ARCH (tobias@T-POWA-LX) (gcc version 4.8.1 (GCC) ) #1 SMP PREEMPT Sun Jul 14 11:00:04 CEST 2013

Although I'm experiencing some issues with nouveau that I wanted to dig into, so I've decided to rebuild kernel from source last Sunday.

I've read/followed the wiki recipes, I've did several attempts with different kernel versions (AUR, ABS, SVN) but in all tries I've got stuck at booting with the following:

:: running early hook [udev]
:: running hook [udev]
:: Triggering uevents...
Waiting 10 seconds for device /dev/sda3 ...
ERROR: device '/dev/sda3' not found. Skipping dsk.
ERROR: Unable tto find root device '/dev/sda3' .
You are being dropped to recovery shell
Type 'exit' to try and continue booting
sh: can't access tty: job control turned off
[rootfs /]# _

So I decided to download the pkgbuild from svn and rebuild the exact version I'm using. I've just changed the pkgbuild to make it -custom and I've got the same result.

Finally I wanted to test the built package so I've installed arch in virtualbox but with grub as bootloader and the package I've generated boots nicely there.

Linux version 3.10.1-1-custom (jep@jepix-nb) (gcc version 4.8.1 (GCC) ) #1 SMP PREEMPT Sun Jul 14 19:08:14 CEST 2013

I've already tried UUID instead of /dev/sda3 on the fstab, digged/compared the initramfs images, ...

About rEFInd, I've installed 0.6.12 version running on EFI Revision 1.10; Platform: x86_64; Secure Boot Inactive; Firmware Apple 1.10, Screen Output (UEFI) 1280x800.

Do you have any clue on what could be causing my builds fail to boot while the builds in the repository doesn't show the issue?

srs5694 · 2013-07-18 16:29:48

adn770 wrote:

Hello
I'm new in Arch linux but I'm already an experienced developer and linux user. I'm facing an strange issue which seems to be related to the topic of this thread.I've got stuck at booting with the following:
:: running early hook [udev]
:: running hook [udev]
:: Triggering uevents...
Waiting 10 seconds for device /dev/sda3 ...
ERROR: device '/dev/sda3' not found. Skipping dsk.
ERROR: Unable tto find root device '/dev/sda3' .
You are being dropped to recovery shell
Type 'exit' to try and continue booting
sh: can't access tty: job control turned off
[rootfs /]# _

This problem is almost certainly not related to the problem under discussion in this thread. I recommend you start a new thread with a title like "local kernel builds fail to boot." As a head-start, I'll say that the problem is most likely related to missing options in your kernel configuration for your disk controller or perhaps even for GPT. You might want to include a link to the .config file for your kernel when you start your new thread, and a description of your disk hardware (especially the disk controller).

WonderWoofy · 2013-07-18 17:22:39

Hopefully without totally derailing this thread, I just want to mention that srs5694 is right that you must be missing the controller or filesystem drivers. But if you are using modified PKGBUILDs from either the AUR or the ABS, you are likely also generating an initramfs to go with those custom kernels. So you might also want to have a look at mkinitpcio (the initrams), and ensure that you have what is necessary there. Of course this is assuming you are not trying to build those things into the kernel itself.

@cfr, I'm curious if there is any news about your work on helping solve your non-boot issue?

Last edited by WonderWoofy (2013-07-18 17:22:59)

cfr · 2013-07-18 20:56:11

@adn770,
As the others said, that's definitely a different issue. You are getting much further in the boot sequence.

@WonderWoofy,
Not yet. I think I've confused things somehow and we've missed something. I'm waiting for advice on which steps, exactly, I need to retrace. The fact that I failed to realise that the source code from git would not boot for me anyway, even with grub, and that it would look indistinguishable in terms of symptoms has obviously not helped. I'm now building against a fixed point but I've missed something somewhere and I'm not sure where or (consequently) what...

Arch Linux

#276 2013-06-12 21:05:22

Re: Kernel 3.7 doesn't boot using EFI Stub

#277 2013-06-12 21:12:25

Re: Kernel 3.7 doesn't boot using EFI Stub

#278 2013-06-12 21:17:54

Re: Kernel 3.7 doesn't boot using EFI Stub

#279 2013-06-12 21:19:33

Re: Kernel 3.7 doesn't boot using EFI Stub

#280 2013-06-15 14:46:28

Re: Kernel 3.7 doesn't boot using EFI Stub

#281 2013-06-19 22:20:17

Re: Kernel 3.7 doesn't boot using EFI Stub

#282 2013-06-27 22:22:05

Re: Kernel 3.7 doesn't boot using EFI Stub

#283 2013-07-03 00:51:15

Re: Kernel 3.7 doesn't boot using EFI Stub

#284 2013-07-03 00:55:24

Re: Kernel 3.7 doesn't boot using EFI Stub

#285 2013-07-03 01:10:23

Re: Kernel 3.7 doesn't boot using EFI Stub

#286 2013-07-03 02:47:55

Re: Kernel 3.7 doesn't boot using EFI Stub

#287 2013-07-03 03:05:10

Re: Kernel 3.7 doesn't boot using EFI Stub

#288 2013-07-03 03:10:53

Re: Kernel 3.7 doesn't boot using EFI Stub

#289 2013-07-06 00:47:30

Re: Kernel 3.7 doesn't boot using EFI Stub

#290 2013-07-09 02:15:47

Re: Kernel 3.7 doesn't boot using EFI Stub

#291 2013-07-09 02:18:08

Re: Kernel 3.7 doesn't boot using EFI Stub

#292 2013-07-09 02:55:13

Re: Kernel 3.7 doesn't boot using EFI Stub

#293 2013-07-09 04:27:57

Re: Kernel 3.7 doesn't boot using EFI Stub

#294 2013-07-10 01:18:37

Re: Kernel 3.7 doesn't boot using EFI Stub

#295 2013-07-10 02:33:53

Re: Kernel 3.7 doesn't boot using EFI Stub

#296 2013-07-10 22:28:53

Re: Kernel 3.7 doesn't boot using EFI Stub

#297 2013-07-18 15:37:27

Re: Kernel 3.7 doesn't boot using EFI Stub

#298 2013-07-18 16:29:48

Re: Kernel 3.7 doesn't boot using EFI Stub

#299 2013-07-18 17:22:39

Re: Kernel 3.7 doesn't boot using EFI Stub

#300 2013-07-18 20:56:11

Re: Kernel 3.7 doesn't boot using EFI Stub

Board footer