Linux kernel unable to boot using EFI

bwright1558 · 2014-01-14 00:59:29

It would appear that UEFI machines fail to boot on seemingly random linux kernel versions, as per this bug report: https://bugs.archlinux.org/task/33745?p … &sort=desc.
After doing some testing, I don't think this is a bug in the linux kernel source code or the PKGBUILD files for the kernel, but rather a problem related to how the Arch developers compile the kernel. Here is the link to a comment I made regarding this issue in the bug report: https://bugs.archlinux.org/task/33745#comment118182. The basis for my hypothesis came from the following comment: https://bugs.archlinux.org/task/33745#comment108126.

How do the Arch developers compile the linux kernel? More specifically, what is the build environment? I believe that there is occasionally something strange about the build environment when the linux kernel is compiled into the tar.xz package. Whatever it is, it is preventing UEFI machines from booting. Currently, mine and other UEFI machines fail to boot using the 3.12.7-1 and 3.12.7-2 kernel from the repositories. My machine successfully boots when I manually compile and install the kernel using the PKGBUILD files for the 3.12.7-2 kernel found here: https://projects.archlinux.org/svntogit … ages/linux.

What are everyone's thoughts on this? How can we get this "fixed?"

Last edited by bwright1558 (2014-01-14 04:16:30)

Stebalien · 2014-01-14 05:49:49

I have the same problem but always compile my own kernels. However, it could be related to the build options set in makepkg.conf.

bwright1558 · 2014-01-14 06:20:12

If you are referring to the makepkg.conf file on my machine, then I am using the default makepkg.conf. I have not made any changes to that file since Arch has been installed on my machine.
As for the makepkg.conf used by the Arch developers creating the tar.xz linux kernel package, maybe that is a starting point for finding an answer to this issue.

WonderWoofy · 2014-01-14 06:24:52

The makepkg.conf file used by the developers is the default as well. The devtools scripts are used to build packages, which uses a fresh and up-to-date clean chroot.

bwright1558 · 2014-01-14 06:42:21

Is it possible for packages to be affected by the hardware in which they are built? Please explain why or why not.

mrunion · 2014-01-14 18:25:48

FWIW, 3.12.7-2 works on my UEFI machine without issues. I do NOT build my own Kernels, this is just the [core] install. Many months ago I had problems with one or two Kernels (I haven't searched the forums to find exact dates) but since then I have had no issues. Also, I use rEFInd, not gummiboot or anything else.

Acer i7, nVidia Optima, 16GB RA, 1T HD.

mcloaked · 2014-01-14 18:46:36

Just to add to the previous poster's comment - I have also been able to boot all stock kernels on my uefi machine using rEFInd since a year or so when arch was first installed. I guess there may be some machine firmwares that are still a little flaky but in general my two uefi machines have had no problems with booting arch stock kernels.

My machine is an Intel DQ77KB motherboard with an I3 CPU and onboard graphics.

Last edited by mcloaked (2014-01-14 18:47:28)

bwright1558 · 2014-01-14 20:41:29

mrunion and mcloaked, what filesystem do you use on your machines? If you have more than one, please list each one and what filesystem they use, i.e., ext4, btrfs, etc. Also label which one is the boot partition and which is the root partition. I also assume you are booting using purely UEFI, i.e., grub/syslinux are not involved in any way during the boot process.

mrunion · 2014-01-15 00:43:10

I use only rEFInd, no grub or syslinux.

My filesystem is ext4 (except for the EFI partition and Windows' NTFS stuff -- which I never boot into and should probably remove!)

sudo lsblk

NAME   MAJ:MIN RM   SIZE RO TYPE MOUNTPOINT
sda      8:0    0 931.5G  0 disk
├─sda1   8:1    0   400M  0 part
├─sda2   8:2    0   300M  0 part
├─sda3   8:3    0   128M  0 part
├─sda4   8:4    0 457.4G  0 part
├─sda5   8:5    0    17G  0 part
├─sda6   8:6    0   512M  0 part /boot/efi
└─sda7   8:7    0 455.8G  0 part /
sr0     11:0    1  1024M  0 rom

sudo fdisk -l

Disk /dev/sda: 931.5 GiB, 1000204886016 bytes, 1953525168 sectors
Units: sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 4096 bytes
I/O size (minimum/optimal): 4096 bytes / 4096 bytes
Disklabel type: gpt
Disk identifier: 40A78FFF-613C-4DF1-A12C-174E57CAF7A8

Device           Start          End   Size Type
/dev/sda1         2048       821247   400M Windows recovery environment
/dev/sda2       821248      1435647   300M EFI System
/dev/sda3      1435648      1697791   128M Microsoft reserved
/dev/sda4      1697792    960935935 457.4G Microsoft basic data
/dev/sda5   1917870080   1953523711    17G Windows recovery environment
/dev/sda6    960935936    961984511   512M EFI System
/dev/sda7    961984512   1917870079 455.8G Linux filesystem

sudo parted -l

Model: ATA ST1000LM024 HN-M (scsi)
Disk /dev/sda: 1000GB
Sector size (logical/physical): 512B/4096B
Partition Table: gpt
Disk Flags:

Number  Start   End     Size    File system  Name                          Flags
 1      1049kB  420MB   419MB   ntfs         Basic data partition          hidden, diag
 2      420MB   735MB   315MB   fat32        EFI system partition          boot
 3      735MB   869MB   134MB                Microsoft reserved partition  msftres
 4      869MB   492GB   491GB   ntfs         Basic data partition
 6      492GB   493GB   537MB   fat32        EFI Arch Linux                boot
 7      493GB   982GB   489GB   ext4         Arch Linux
 5      982GB   1000GB  18.3GB  ntfs         Basic data partition          hidden, diag

bwright1558 · 2014-01-15 01:25:59

Thanks mrunion. This leads me to suspect that the issue is specifically hardware related. Feel free to follow us and make constructive comments in the related bug report: https://bugs.archlinux.org/task/33745?p … &sort=desc.

mrunion · 2014-01-15 01:50:01

I'll help as best I can. Thanks!

hukbert · 2014-01-15 07:47:02

FWIW, I've had the same problem for a couple of days now (same symptoms as in the related bug report), and found that my (local) kernel does boot simply if rEFInd detects another linux bootloader on a plugged-in USB flash drive (note that I do not boot into the system on this USB flash drive, but into Arch on my HDD)... This seems pretty weird to me, and being a bit of a noob I have no idea how to debug this problem. But perhaps someone finds this info useful.

mcloaked · 2014-01-15 08:38:50

mrunion wrote:

I use only rEFInd, no grub or syslinux.

My filesystem is ext4 (except for the EFI partition and Windows' NTFS stuff -- which I never boot into and should probably remove!)

sudo lsblk

NAME   MAJ:MIN RM   SIZE RO TYPE MOUNTPOINT
sda      8:0    0 931.5G  0 disk
├─sda1   8:1    0   400M  0 part
├─sda2   8:2    0   300M  0 part
├─sda3   8:3    0   128M  0 part
├─sda4   8:4    0 457.4G  0 part
├─sda5   8:5    0    17G  0 part
├─sda6   8:6    0   512M  0 part /boot/efi
└─sda7   8:7    0 455.8G  0 part /
sr0     11:0    1  1024M  0 rom

sudo fdisk -l

Disk /dev/sda: 931.5 GiB, 1000204886016 bytes, 1953525168 sectors
Units: sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 4096 bytes
I/O size (minimum/optimal): 4096 bytes / 4096 bytes
Disklabel type: gpt
Disk identifier: 40A78FFF-613C-4DF1-A12C-174E57CAF7A8

Device           Start          End   Size Type
/dev/sda1         2048       821247   400M Windows recovery environment
/dev/sda2       821248      1435647   300M EFI System
/dev/sda3      1435648      1697791   128M Microsoft reserved
/dev/sda4      1697792    960935935 457.4G Microsoft basic data
/dev/sda5   1917870080   1953523711    17G Windows recovery environment
/dev/sda6    960935936    961984511   512M EFI System
/dev/sda7    961984512   1917870079 455.8G Linux filesystem

sudo parted -l

Model: ATA ST1000LM024 HN-M (scsi)
Disk /dev/sda: 1000GB
Sector size (logical/physical): 512B/4096B
Partition Table: gpt
Disk Flags:

Number  Start   End     Size    File system  Name                          Flags
 1      1049kB  420MB   419MB   ntfs         Basic data partition          hidden, diag
 2      420MB   735MB   315MB   fat32        EFI system partition          boot
 3      735MB   869MB   134MB                Microsoft reserved partition  msftres
 4      869MB   492GB   491GB   ntfs         Basic data partition
 6      492GB   493GB   537MB   fat32        EFI Arch Linux                boot
 7      493GB   982GB   489GB   ext4         Arch Linux
 5      982GB   1000GB  18.3GB  ntfs         Basic data partition          hidden, diag

My system is very similar to the above except I only have the ESP, a root partition, /opt and swap. These also are all ext4 except for the ESP which is FAT32, and swap. I don't have Windows on my machine. I also only used rEFInd and not grub/gummiboot/syslinux. The way I set up my partitions was that /boot/efi is the FAT32 partition for the ESP, and then make a my ESP partition as /boot/efi/EFI/ which contains the rEFInd binary. Then my root partition is ext4 as / and I make a directory within that /boot which is also ext4. I utilise the rEFInd ext4 drivers from that package so that the /boot partition can be read by rEFInd and so the normal arch kernel updates put the kernel and initramfs into /boot (ext4) and the rEFInd binary reads it perfectly happily using its ext4 drivers. It also means that kernel updates need no manual intervention, and the system can be simply rebooted after the pacman update.

I hope that helps.

mrunion · 2014-01-15 13:51:20

@mcloaked: I don't do the "automatic Kernel update" thing, or use the ext4 drivers for rEFInd. Any time there is a Kernel install, I manually run my back up script, then the update-the-kernel-for-rEFInd script. My actual EFI Kernel lives at /boot/efi/EFI/arch. (I also copy over and update rEFInd whenever it's updated as well.)

I have my doubts that your way or mine affects the booting of the Kernel, but I included my difference here just in case someone thinks it might.

mcloaked · 2014-01-15 18:43:20

mrunion wrote:

@mcloaked: I don't do the "automatic Kernel update" thing, or use the ext4 drivers for rEFInd. Any time there is a Kernel install, I manually run my back up script, then the update-the-kernel-for-rEFInd script. My actual EFI Kernel lives at /boot/efi/EFI/arch. (I also copy over and update rEFInd whenever it's updated as well.)
I have my doubts that your way or mine affects the booting of the Kernel, but I included my difference here just in case someone thinks it might.

Just a stab in the dark but when I first installed my system I found that I did have problems booting the kernel. Although it may not be related to your particular issue the problem I had at the time was that efibootmgr wrote faulty entries in the NVRAM, and I eventually solved this with help from Rod Smith by writing the NVRAM entry using the bcfg command from an efi shell v2 booted from the arch install usb. Using bcfg to write the entry in the motherboard chip gave a solid boot for me from then on. I don't know if efibootmgr has subsequently been fixed so that it is no longer buggy but it may be worth a try to see if that helps possibly?

Anyway just another idea to throw in the mix.

Also rather than rEFInd selecting kernels to boot automatically it is perfectly possible to write rEFInd boot stanzas to define any number of entries that can be on the rEFInd list of items that can be booted, and then control which entries you want to boot, including Windows - there is documentation for that for rEFInd.

Last edited by mcloaked (2014-01-15 18:45:18)

mrunion · 2014-01-15 23:44:22

Does this info help? I got it from the rEFInd Shell v 1.0 by running "ver":

EFI Specification Revision: 2.31
EFI Vendor: INSYDE Corp.
EFI Revision: 4096.1

I don't know if any of that stuff is relevant.

mrunion · 2014-01-22 13:54:42

FWIW, I upgraded to 3.12.8-1 yesterday, and on the first boot afterwards I was stuck just after you see the boot params from rEFInd. I continually rebooted over and over and tried to start the kernel from the shell, and eventually the problem just "went away"(TM) after about 6 boots. I gave it no more thought until this morning -- same thing happened again. This time after trying about 15 reboots to no avail, I plugged in a USB thumb drive -- just some files on it -- and it booted fine.

I am downgrading to 3.12.7-2 to see if the problems disappear.

Do you guys think this is related to this thread, or should I start a new discussion? (A quick search turned up no problems similar to mine.)

----->

UPDATE: I looked through the journal and know that the boot process must never get far enough to even log anything, as the only think in the log fro today was the successful boot with the USB drive installed. Apparently it fails early enough that no logging is started. I assume that this is a failure in the "stub loader" (is that what it's called)? I don't have gummiboot configured, only rEFInd. I may try to set up gummiboot and see if it makes a difference.

Last edited by mrunion (2014-01-22 15:35:41)

WonderWoofy · 2014-01-22 16:25:53

@mrunion, yes I think that this is related. I think this is an issue either with the EFISTUB functionality, or the firmware of the machine. Maybe both. But if that is the case and it really is the EFISTUB, then it would explain why nothing is getting logged since it technically isn't getting past the bootloader.

Edit: splling

Last edited by WonderWoofy (2014-01-22 16:26:34)

mrunion · 2014-01-23 14:27:46

Another update:

The machine WILL boot 3.12.8 using BOTH rEFInd and Gummiboot, but ONLY if I plug a USB thumb drive (ANY thumb drive) into a USB port. The thumb drives I've tried are NOT boot drives, just regular old file storage drives.

I have no clue now.....

P.S. I updated ticket FS#33745 (https://bugs.archlinux.org/task/33745?p … &sort=desc)

Last edited by mrunion (2014-01-23 14:28:45)

mrunion · 2014-01-23 15:35:01

OK, I [SOLVED] my problem! Obviously it is not the solution for everybody (anybody) else, but here is the results:

I check my BIOS version against what Acer said mine should be for the V3-771G. I had 2.16 and the latest update was 2.23. I cringed, but updated my BIOS to 2.23. I had to reset the boot options to boot rEFInd again, but after that the machine booted just fine -- no USB thumb drive required.

Obviously, everyone else's mileage will vary, but does this not give some indication that whatever is being done at the earliest levels of the Kernel booting is affected by something in the BIOS?

Also, I only tested rebooting a couple of times. This may cause other issues down the road, or in fact not have completely solved my problem, and I just "lucked up" for a couple of boots. I will also update ticket FS#33745 in the bug tracker with this same info.

ewaller · 2014-01-23 15:50:41

... or perhaps Acer recognized the wisdom in creating a standards compliant EFI so they are not locked into selling machines that will only run operating systems that emerge from the Pacific Northwest. I am just saying....

mrunion · 2014-01-23 18:00:30

ewaller:

(I hope this is the reason!)

dhave · 2014-01-30 05:54:20

Like others, I've been having problems booting more recent kernel releases using UEFI via rEFInd. When I read mrunion's post above about getting his machine to boot simply by sticking a thumb drive in a USB port, I tried that, and was amazed to see that it worked for me, too. (Like mrunion's, my thumb drive is just miscellaneous data; no kernel or initramfs img files.)

When I read a follow-up post from mrunion about how his problem was finally resolved by updating his BIOS, I checked the Lenovo site and found that, sure enough, my machine was using the next-to-latest BIOS. So I updated to the current BIOS and rebooted with high hopes. For me, this didn't fix things.

I'm running a Lenovo Thinkpad T420, booting UEFI only via rEFInd. When a new kernel comes out, I install it using pacman, then copy over the kernel and initramfs img files to my EFI partition, where I rename them each with an indication of the release number. Then rEFInd discovers that new kernel and presents it as a boot option. But it will boot *only* when there's a USB thumb drive in place. So weird.

mrunion · 2014-01-30 13:41:48

I'm glad the thumb drive trick works for you. It came from the FS#33745 ticket on the Bug Tracker (if I recall correctly). But it is unfortunate a BIOS update didn't fix the issue. I'm confident the Kernel people will eventually figure out what the deal is though!

(If you've not already, I think it would be informative to update FS#33745 on the bug tracker with your info as well.)

WonderWoofy · 2014-01-30 18:21:49

@dhave, if you are willing, you should try compiling your own kernel. Just use ABS to get the PKGBUILD and accompanying files, then just 'makepkg' it. You don't have to configure or change anything. I have seen several reports that self compiled kernels seem to work when the offical -ARCH kernels don't, even when the same exact config is applied and compiled with the same gcc.

Edit: If you really wanted to do it exactly like the official kernel is made, you could use devtools to do it as well. But I don't know that a clean chroot would really affect anything in this case.

Last edited by WonderWoofy (2014-01-30 18:22:29)

Arch Linux

#1 2014-01-14 00:59:29

Linux kernel unable to boot using EFI

#2 2014-01-14 05:49:49

Re: Linux kernel unable to boot using EFI

#3 2014-01-14 06:20:12

Re: Linux kernel unable to boot using EFI

#4 2014-01-14 06:24:52

Re: Linux kernel unable to boot using EFI

#5 2014-01-14 06:42:21

Re: Linux kernel unable to boot using EFI

#6 2014-01-14 18:25:48

Re: Linux kernel unable to boot using EFI

#7 2014-01-14 18:46:36

Re: Linux kernel unable to boot using EFI

#8 2014-01-14 20:41:29

Re: Linux kernel unable to boot using EFI

#9 2014-01-15 00:43:10

Re: Linux kernel unable to boot using EFI

#10 2014-01-15 01:25:59

Re: Linux kernel unable to boot using EFI

#11 2014-01-15 01:50:01

Re: Linux kernel unable to boot using EFI

#12 2014-01-15 07:47:02

Re: Linux kernel unable to boot using EFI

#13 2014-01-15 08:38:50

Re: Linux kernel unable to boot using EFI

#14 2014-01-15 13:51:20

Re: Linux kernel unable to boot using EFI

#15 2014-01-15 18:43:20

Re: Linux kernel unable to boot using EFI

#16 2014-01-15 23:44:22

Re: Linux kernel unable to boot using EFI

#17 2014-01-22 13:54:42

Re: Linux kernel unable to boot using EFI

#18 2014-01-22 16:25:53

Re: Linux kernel unable to boot using EFI

#19 2014-01-23 14:27:46

Re: Linux kernel unable to boot using EFI

#20 2014-01-23 15:35:01

Re: Linux kernel unable to boot using EFI

#21 2014-01-23 15:50:41

Re: Linux kernel unable to boot using EFI

#22 2014-01-23 18:00:30

Re: Linux kernel unable to boot using EFI

#23 2014-01-30 05:54:20

Re: Linux kernel unable to boot using EFI

#24 2014-01-30 13:41:48

Re: Linux kernel unable to boot using EFI

#25 2014-01-30 18:21:49

Re: Linux kernel unable to boot using EFI

Board footer