EFI stub loader broken in kernel 3.13.0-101-generic (& later in 3.13 series)

[Rod Smith]

The EFI stub loader produces consistent boot errors when booting Trusty starting with version 3.13.0-101-generic. This bug can be reproduced in many ways (using efibootmgr, an EFI shell, rEFInd, etc.). One approach is:

1) Install an EFI shell on the computer and set it as the default boot
   option using efibootmgr.
2) Copy the kernel and initrd files from /boot to /boot/efi.
3) Rename the kernel file to use a .efi filename extension.
4) Reboot into the EFI shell.
5) Try to launch the kernel with a command like:
   fs0:\vmlinuz-3.13.0-104-generic.efi ro root=/dev/sda2 initrd=\initrd.img-3.13.0-104-generic

The result will be a hung or crashed system. (In VirtualBox, in which I've tested this, the VM produces a "guru meditation" and the session terminates.)

I myself have tested only with the 3.13.0-104 kernel; however, reports from others indicate that the problem began with the 3.13.0-101 kernel. See this Kubuntu forum thread for details:

https://www.kubuntuforums.net/showthread.php?71204-Cannot-load-latest-kernels

Note that early on, this thread focuses on rEFInd; however, the bug can be reproduced with other boot managers, including the EFI shell, as described in the preceding procedure, so I do not believe this is a rEFInd bug. rEFInd relies on the EFI stub loader to boot a Linux kernel, and I believe it's this component that's failing. The problem does NOT occur when using GRUB to launch the kernel. (GRUB does not rely on the EFI stub loader.)

I have NOT encountered the problem with Xenial and its 4.4.0-series kernels (last tested: 4.4.0-53-generic) or Yakkety and its 4.8.0-series kernels (last tested: 4.8.0-30-generic). I have not yet tested Trusty with kernels from series beyond 3.13.0.
---
ApportVersion: 2.14.1-0ubuntu3.21
Architecture: amd64
AudioDevicesInUse:
 USER PID ACCESS COMMAND
 /dev/snd/controlC0: rodsmith 1675 F.... pulseaudio
CurrentDesktop: LXDE
DistroRelease: Ubuntu 14.04
HibernationDevice: RESUME=UUID=561add6d-844e-4428-8378-d92bb112d0fc
InstallationDate: Installed on 2014-04-27 (960 days ago)
InstallationMedia: Ubuntu 14.04 LTS "Trusty Tahr" - Release amd64 (20140417)
IwConfig:
 eth0 no wireless extensions.

 lo no wireless extensions.
Lsusb:
 Bus 001 Device 002: ID 80ee:0021 VirtualBox USB Tablet
 Bus 001 Device 001: ID 1d6b:0001 Linux Foundation 1.1 root hub
MachineType: innotek GmbH VirtualBox
Package: linux (not installed)
ProcFB: 0 EFI VGA
ProcKernelCmdLine: BOOT_IMAGE=/boot/vmlinuz-3.13.0-106-generic root=UUID=78ff568b-2c22-4b31-9e0c-72703dca4460 ro quiet splash vt.handoff=7
ProcVersionSignature: Ubuntu 3.13.0-106.153-generic 3.13.11-ckt39
RelatedPackageVersions:
 linux-restricted-modules-3.13.0-106-generic N/A
 linux-backports-modules-3.13.0-106-generic N/A
 linux-firmware 1.127.22
RfKill:

Tags: trusty
Uname: Linux 3.13.0-106-generic x86_64
UpgradeStatus: No upgrade log present (probably fresh install)
UserGroups: adm cdrom dip lpadmin plugdev sambashare sudo
_MarkForUpload: True
dmi.bios.date: 12/01/2006
dmi.bios.vendor: innotek GmbH
dmi.bios.version: VirtualBox
dmi.board.name: VirtualBox
dmi.board.vendor: Oracle Corporation
dmi.board.version: 1.2
dmi.chassis.type: 1
dmi.chassis.vendor: Oracle Corporation
dmi.modalias: dmi:bvninnotekGmbH:bvrVirtualBox:bd12/01/2006:svninnotekGmbH:pnVirtualBox:pvr1.2:rvnOracleCorporation:rnVirtualBox:rvr1.2:cvnOracleCorporation:ct1:cvr:
dmi.product.name: VirtualBox
dmi.product.version: 1.2
dmi.sys.vendor: innotek GmbH

[Brad Figg (brad-figg)]

This bug is missing log files that will aid in diagnosing the problem. From a terminal window please run:

apport-collect 1649326

and then change the status of the bug to 'Confirmed'.

If, due to the nature of the issue you have encountered, you are unable to run this command, please add a comment stating that fact and change the bug status to 'Confirmed'.

This change has been made by an automated script, maintained by the Ubuntu Kernel Team.

[Joseph Salisbury (jsalisbury)]

Can you see if this bug still exists in the 3.13.0-106 kernel? It can be downloaded from:
https://launchpad.net/~canonical-kernel-team/+archive/ubuntu/ppa/+build/11527714

If it does, can you see if this bug happens with the 3.13.0-100 kernel? It can be downloaded from:
https://launchpad.net/~canonical-kernel-security-team/+archive/ubuntu/ppa/+build/11039050

Both these kernel required installing both the linux-image and linux-image-extra .deb packages.

[mike (mikeq)]

I can confirm this problem in Kubuntu 14.04 on two kernels:
vmlinuz-3.13.0-103-generic-efi.signed, in 14.04
vmlinuz-3.13.0-105-generic-efi.signed, in 14.04

(The details of my test are in the thread Rod Smith cited:
https://www.kubuntuforums.net/showthread.php?71204-Cannot-load-latest-kernels&p=396267&viewfull=1#post396267 -- I have no problem booting the kernel vmlinuz-3.13.0-100-generic-efi.signed, in 14.04 directly by UEFI using stub loader (on an ASUS H97-PLUS motherboard).)

[mike (mikeq)]

I can confirm this problem in Kubuntu 14.04 on:
vmlinuz-3.13.0-101-generic.

So, to summarize my tests, in Kubuntu 14.04,
I do NOT have the problem with vmlinuz-3.13.0-100-generic.
I do, however, have the problem with the following three kernels:
vmlinuz-3.13.0-101-generic
vmlinuz-3.13.0-103-generic
vmlinuz-3.13.0-105-generic

(I really don't have the advanced skills it might take to go deeper into this. All my basic work is simply done at Konsole in Kubuntu using efibootmgr -c commands and such.)

[Rod Smith (rodsmith)]

apport information

[Rod Smith (rodsmith)]

apport information

[Rod Smith (rodsmith)]

apport information

[Rod Smith (rodsmith)]

apport information

[Rod Smith (rodsmith)]

apport information

[Rod Smith (rodsmith)]

apport information

[Rod Smith (rodsmith)]

apport information

[Rod Smith (rodsmith)]

apport information

[Rod Smith (rodsmith)]

apport information

[Rod Smith (rodsmith)]

apport information

[Rod Smith (rodsmith)]

apport information

[Rod Smith (rodsmith)]

apport information

[Rod Smith (rodsmith)]

apport information

[Rod Smith (rodsmith)]

I've tried with 3.13.0-100 and it worked. I tried with 3.13.0-106 and it failed.

I've attached the requested apport-collect information from a 3.13.0-106 kernel; however, because of the nature of the bug, I had to boot that kernel via GRUB 2, not via the EFI stub loader. The apport-collect information was collected inside a VirtualBox VM.

[Joseph Salisbury (jsalisbury)]

I started a kernel bisect between 3.13.0-100 and 3.13.0-101. The kernel bisect will require testing of about 6 test kernels.

I built the first test kernel, up to the following commit:
b9d249e8599e305f77dfc83c5bd9dadef87d4e23

The test kernel can be downloaded from:
http://kernel.ubuntu.com/~jsalisbury/lp1649326

Can you test that kernel and report back if it has the bug or not? I will build the next test kernel based on your test results.

Thanks in advance

[Rod Smith (rodsmith)]

The lp1649326 version failed to boot for me, but in a different way from the others on SOME launches -- rather than crashing VirtualBox with a "guru meditation" dialog box, it displayed the following messages within the emulated environment:

failed to get file info size
failed to alloc highmem for files

The VM then hung. This occurred when I launched using VirtualBox's built-in EFI shell or when I launched from rEFInd. When I launched from an EFI shell that was in turn launched by rEFInd, VirtualBox produced the same "guru meditation" dialog box followed by a VM crash described earlier.

[Rod Smith (rodsmith)]

The plot thickens; it seems that this bug, or at least a variant of it, may have existed as far back as 3.13.0-92. See this post in the Kubuntu forums thread:

https://www.kubuntuforums.net/showthread.php?71204-Cannot-load-latest-kernels&p=396273&viewfull=1#post396273

I've tested the 3.13.0-92 kernel and found that it hangs with the "failed to get file info size" and "failed to alloc highmem for files" messages on four of five test launches from rEFInd, the VirtualBox EFI shell, or an EFI shell launched from rEFInd; however, on one test launch (from VirtualBox's EFI shell), the boot succeeded. I thought I saw at least the first of the messages flash on the screen before the boot completed, though. This version of the kernel has not produced the VirtualBox "guru meditation" dialog box and subsequent crash.

[Rod Smith (rodsmith)]

More kernels in that range:

* 3.13.0-91: OK
* 3.13.0-92: Bad
* 3.13.0-93: OK
* 3.13.0-95: OK
* 3.13.0-96: OK
* 3.13.0-98: OK

I installed all of these via "sudo apt-get install linux-image-extra-{version}-generic". Versions not noted between 3.13.0-90 and 3.13.0-99 were reported by apt-get as being unavailable. I tested most of them with rEFInd alone for simplicity.

[Joseph Salisbury (jsalisbury)]

For the test kernel in comment #19, did you install both the linux-image and linux-image-extra .deb packages?

[Rod Smith (rodsmith)]

Yes, I installed both linux-image and linux-image-extra for all the kernels.

[Rod Smith (rodsmith)]

Joseph, any more kernels for me to test? It's been a while.

Also, I ran across bug #1603476, which reports a failure with kernel 3.13.0-92 that might (or might not) be related to this.

[Joseph Salisbury (jsalisbury)]

Sorry for the delay. I skipped commit b9d249e8 in the bisect.

I built the next test kernel, up to the following commit:
5bd4d89ffc2f0fe54b752f2dc05706d277459089

The test kernel can be downloaded from:
http://kernel.ubuntu.com/~jsalisbury/lp1649326

Can you test that kernel and report back if it has the bug or not? I will build the next test kernel based on your test results.

Could you also see if this bug also exists in the latest mainline kernel? It is available from:
http://kernel.ubuntu.com/~kernel-ppa/mainline/v4.10-rc3/

[Rod Smith (rodsmith)]

The linux-image-3.13.0-101-generic_3.13.0-101.148~lp1649326Commit5bd4d89ffc2_amd64.deb (with linux-image-extra-3.13.0-101-generic_3.13.0-101.148~lp1649326Commit5bd4d89ffc2_amd64.deb) kernel failed with the "failed to get file info size/failed to alloc highmem for files" messages noted earlier.

The linux-image-4.10.0-041000rc3-generic_4.10.0-041000rc3.201701081831_amd64.deb kernel booted without problems.

Both tests were in a VirtualBox VM.

[Joseph Salisbury (jsalisbury)]

That's good news that 4.10-rc3 fixes the bug. I think it would be best to perform a "Reverse" bisect to identify the fix that is already upstream versus continuing a regular bisect to find the commit that introduced the bug.

For a reverse bisect, we need to find the last bad kernel version and first good one. We now know that v4.10-rc3 is good. Can you next text 4.10-rc1? It is available from:

http://kernel.ubuntu.com/~kernel-ppa/mainline/v4.10-rc1

If 4.10-rc1 is good, we would want to test 4.9 and it's release candidates, then if needed, 4.8, etc.

[Rod Smith (rodsmith)]

Joseph, please note the following from the original bug report:

I have NOT encountered the problem with Xenial and its 4.4.0-series kernels (last tested: 4.4.0-53-generic) or Yakkety and its 4.8.0-series kernels (last tested: 4.8.0-30-generic). I have not yet tested Trusty with kernels from series beyond 3.13.0.

[Joseph Salisbury (jsalisbury)]

Thanks for the update. That means we should start testing prior to 4.4. Can you test 3.16 final:

http://kernel.ubuntu.com/~kernel-ppa/mainline/v3.16-utopic/

[Rod Smith (rodsmith)]

The linux-image-3.16.0-031600-generic kernel boots fine.

[Joseph Salisbury (jsalisbury)]

Thanks for testing! Can you next test 3.14 final:

http://kernel.ubuntu.com/~kernel-ppa/mainline/v3.14-trusty/

[Rod Smith (rodsmith)]

linux-image-3.14.0-031400-generic also boots fine.

[Joseph Salisbury (jsalisbury)]

Can you next test v3.14-rc1:

http://kernel.ubuntu.com/~kernel-ppa/mainline/v3.14-rc1-trusty/

[Rod Smith (rodsmith)]

linux-image-3.14.0-031400rc1-generic also boots fine.

[Joseph Salisbury (jsalisbury)]

Can you test v3.13 final:
http://kernel.ubuntu.com/~kernel-ppa/mainline/v3.13-trusty/

If it fails, we can "Reverse" bisect between v3.13 and v3.14-rc1. If v3.13 final boots fine, then that would indicate an Ubuntu specific SAUCE patch causing the bug.

[Rod Smith (rodsmith)]

The linux-image-3.13.0-031300 kernel boots fine, Joseph.

[Joseph Salisbury (jsalisbury)]

Thanks for the update. This indicates an Ubuntu sauce patch is the cause of the regression.

To confirm this, can you test the v3.13.11-ckt39 upstream kernel? This is the kernel Ubuntu 3.13.0-101 is based on:

http://kernel.ubuntu.com/~kernel-ppa/mainline/v3.13.11-ckt39-trusty/

[Rod Smith (rodsmith)]

Joseph, the 3.13.11-ckt39 kernel boots fine.

[Joseph Salisbury (jsalisbury)]

This would indicate that the bug was introduced by a SAUCE patch in Trusty. We also know that this bug is fixed in Xenial, so there is another patch that fixes this regression that has not made it into Trusty.

I think the next step should be to identify the patch in Xenial and backport it to Trusty.

Can you test the 3.19 based Vivid kernel? It can be downloaded from:
https://launchpad.net/~canonical-kernel-team/+archive/ubuntu/ppa/+build/11760211

[Rod Smith (rodsmith)]

Joseph, the 3.19.0-79.87 kernel boots fine.

[Joseph Salisbury (jsalisbury)]

I reviewed the git logs and there were allot of efi changes in 3.13.0-101. Here is a list:

406bcddd9857 x86/reboot: Add EFI reboot quirk for ACPI Hardware Reduced flag
dddbb2cd38ff x86/efi: Fix boot crash by mapping EFI memmap entries bottom-up at runtime, instead of top-down
bf3b58763565 efi: Disable interrupts around EFI calls, not in the epilog/prolog calls
68ac78b66414 x86/efi: Implement a __efi_call_virt macro
76deae345d9e x86/efi: Delete most of the efi_call* macros
fe1e82232ed4 UBUNTU: SAUCE: merge with v3.15
5bd4d89ffc2f x86/efi: Rip out phys_efi_get_time()
3f049eaef571 UBUNTU: SAUCE: Merge remote-tracking branch 'tip/x86/efi-mixed' into efi-for-mingo
59ed4b67da79 x86/efi: Wire up CONFIG_EFI_MIXED
daa829de21e9 x86/efi: Delete dead code when checking for non-native
6edf5236f210 x86/efi: Split efi_enter_virtual_mode
0dc405eb8e11 x86/efi: Make efi virtual runtime map passing more robust
68c47ffe8bb0 x86/efi: Dump the EFI page table
bcdf5feaecae x86/efi: Style neatening
f162bc96a0d2 x86/efi: Delete out-of-date comments of efi_query_variable_store
78c8a6942cc5 efi: Set feature flags inside feature init functions
c25eaae2c28f efi: Move facility flags to struct efi
f27702352afe x86/efi: Quirk out SGI UV
f1ef6ec21389 x86/efi: Fix 32-bit fallout
c77a8e25d784 UBUNTU: SAUCE: Merge tag 'v3.13-rc7' into x86/efi-kexec to resolve conflicts
63a426527734 x86/efi: Delete superfluous global variables
c8adf92ae1a0 x86/efi: Pass necessary EFI data for kexec via setup_data
74bdcac0c014 efi: Export EFI runtime memory mapping to sysfs
db7b55fcecc4 efi: Export more EFI table variables to sysfs
fd610615acf3 x86/efi: Cleanup efi_enter_virtual_mode() function
4c01cc70618b x86/efi: Fix off-by-one bug in EFI Boot Services reservation
528f2d29e8f1 UBUNTU: SAUCE: Merge tag 'efi-next' of git://git.kernel.org/pub/scm/linux/kernel/git/mfleming/efi into x86/efi
a058d6f91746 x86/efi: Check krealloc return value
a14015f4799d x86/efi: Runtime services virtual mapping
177ead2c3dff x86/efi: Simplify EFI_DEBUG
bf963b4f71da Revert "x86/efi: Fix off-by-one bug in EFI Boot Services reservation"
4a394e4cd9d7 Revert "x86/efi: Runtime services virtual mapping"
033a9865e181 Revert "x86/efi: Check krealloc return value"
11cd444bf961 Revert "x86/efi: Fix 32-bit fallout"
be7a87ad04b8 Revert "efi: Disable interrupts around EFI calls, not in the epilog/prolog calls"

I think I may have to bisect manually to figure out which of these commits is the culprit. To narrow it down, I built a kernel up to commit 528f2d29e8f1.

The test kernel can be downloaded from:
http://kernel.ubuntu.com/~jsalisbury/lp1649326/528f2d2

Can you test that kernel and report back if it has the bug or not? I will build the next test kernel based on your test results.

[Rod Smith (rodsmith)]

The linux-image-3.13.0-101-generic_3.13.0-101.148~lp1649326Commit528f2d2_amd64.deb kernel boots correctly.

[Joseph Salisbury (jsalisbury)]

I built the next test kernel, up to the following commit:
74bdcac

The test kernel can be downloaded from:
http://kernel.ubuntu.com/~jsalisbury/lp1649326/74bdcac

Can you test that kernel and report back if it has the bug or not?

[Rod Smith (rodsmith)]

Joseph, the linux-image-3.13.0-101-generic_3.13.0-101.148~lp1649326Commit74bdcac_amd64.deb kernel also boots correctly.

[Joseph Salisbury (jsalisbury)]

I built the next test kernel, up to the following commit:
59ed4b6

The test kernel can be downloaded from:
http://kernel.ubuntu.com/~jsalisbury/lp1649326/74bdcac

Can you test that kernel and report back if it has the bug or not?

[Rod Smith (rodsmith)]

Joseph,

I think there was a typo in your URL, since it was the same as from the previous test. Since you noted a different commit number, I adjusted and pulled the kernel from:

http://kernel.ubuntu.com/~jsalisbury/lp1649326/59ed4b6/

This kernel fails to boot, with the "failed to get file info size/failed to alloc highmem for files" message as noted in post #20 of this bug report, rather than VirtualBox crashing, as described in my original bug report description.

[Joseph Salisbury (jsalisbury)]

Sorry about the type.

I built the next test kernel, up to the following commit:
f162bc9

The test kernel can be downloaded from:
http://kernel.ubuntu.com/~jsalisbury/lp1649326/f162bc9

[Rod Smith (rodsmith)]

The linux-image-3.13.0-101-generic_3.13.0-101.148~lp1649326Commitf162bc9_amd64.deb kernel boots fine.

[Joseph Salisbury (jsalisbury)]

I built the next test kernel, up to the following commit:
6edf523

The test kernel can be downloaded from:
http://kernel.ubuntu.com/~jsalisbury/lp1649326/6edf523

[Rod Smith (rodsmith)]

linux-image-3.13.0-101-generic_3.13.0-101.148~lp1649326Commit6edf523 boots fine for me.

[Joseph Salisbury (jsalisbury)]

I built the next test kernel with commit 59ed4b6 reverted.
The test kernel can be downloaded from:
http://kernel.ubuntu.com/~jsalisbury/lp1649326/commit-59ed4b67da-reverted

Can you give this kernel a try?

[Rod Smith (rodsmith)]

Joseph, I don't see the usual linux-image-* files at that URL. Could you please double-check that and fix as necessary?

[Joseph Salisbury (jsalisbury)]

Sorry the kernel build with that commit reverted failed. I'll investigate further.

[Joseph Salisbury (jsalisbury)]

I built a test kernel up to commit daa829d.
The test kernel can be downloaded from:
http://kernel.ubuntu.com/~jsalisbury/lp1649326/daa829d

Can you give this kernel a try while I investigate the revert failure of commit 59ed4b6? This test kernel should be good, but just want to confirm.

[Rod Smith (rodsmith)]

The linux-image-3.13.0-101-generic_3.13.0-101.148~lp1649326Commitdaa829d kernel boots fine for me.

[Joseph Salisbury (jsalisbury)]

It looks like reverting commit 59ed4b6 requires several other commits get reverted, so it's probably not the best approach.

We know that this bug is fixes in Xenial. It's probably best to track down what commit fixes this in Xenial versus what commit broke this in Trusty.

In comment 41, we found the 3.19 kernel is good, so we should test some earlier ones. Can you test the following 3.16 kernel:

https://launchpad.net/ubuntu/+source/linux/3.16.0-23.31/+build/6478448

You would need to install both the linux-image and linux-image-extra .deb packages.

Thanks

[Rod Smith (rodsmith)]

The linux-image-3.16.0-23-generic_3.16.0-23.31_amd64.deb kernel (with its associated "extra" package) boots fine for me.

[Joseph Salisbury (jsalisbury)]

I built a v3.15.0-0.1 test kernel. The test kernel can be downloaded from:
http://kernel.ubuntu.com/~jsalisbury/lp1649326/v3.15.0-0.1

Can you see if this kernel has the bug?

[Rod Smith (rodsmith)]

The 3.15.0-0.1 kernel boots fine for me.

[Joseph Salisbury (jsalisbury)]

I built a v3.13.0-9.29 test kernel. The test kernel can be downloaded from:
http://kernel.ubuntu.com/~jsalisbury/lp1649326/v3.13.0-9.29

Can you see if this kernel has the bug?

[Rod Smith (rodsmith)]

The kernel in linux-image-3.13.0-9-generic_3.13.0-9.29~lp1649326_amd64.deb boots fine for me.

Also, the newly-release 3.13.0-108 kernel in the regular repos does NOT boot; it crashes like everything else since 3.13.0-101.

[Rod Smith (rodsmith)]

I just did an "apt-get dist-upgrade", and I see there's now a 3.13.0-110 kernel, too. It also crashes.

[Joseph Salisbury (jsalisbury)]

I built a test kernel up to commit 3f049ea.

The test kernel can be downloaded from:
http://kernel.ubuntu.com/~jsalisbury/lp1649326/3f049ea

Can you give this kernel a try?

[Rod Smith (rodsmith)]

The kernel in linux-image-3.13.0-101-generic_3.13.0-101.148~lp1649326Commit3f049ea_amd64.deb fails to boot, but in different ways that seem to be somewhat random:

* Sometimes the warnings "Failed to get file info size" and
  "Failed to alloc highmem for files" appear.
* Sometimes, when launching from rEFInd, the above messages
  appear along with ASSERT messages from the UDK2014 tool
  kit used to build rEFInd, as shown in boot-failure.png.
* Sometimes the message (shown in boot-failure.png) "ASSERT
  fsw_efi.c(674): CR has Bad Signature" scrolls across the
  screen and fills it entirely. (Note that fsw_efi.c is a
  rEFInd filesystem driver file; however, I've also tested
  booting the kernel from the FAT32 ESP, and even with the
  rEFInd filesystem driver never loaded, and the kernel still
  fails to boot, so this is not a filesystem driver problem
  per se.)
* Sometimes (usually when doing a cold boot), the kernel
  loads but then panics, as shown in boot-failure-2.png.

Note that I've tried to boot this kernel in many ways -- via rEFInd, via the VirtualBox EFI shell; from the ext4fs root (/) filesystem via the rEFInd ext4fs driver, and from the FAT32 ESP; cold booting and warm booting. None of these approaches has worked, but the failure symptoms vary and are somewhat inconsistent, even when booting in exactly the same way -- sometimes the screen hangs with errors, other times that scrolling message about "CR has Bad Signature" appears; and error messages can vary randomly from one attempt to another.

[Rod Smith (rodsmith)]

Joseph,

Do you have more kernels for me to test? It's been a while since you gave me the last one....

[Rod Smith (rodsmith)]

Dimitrenko, I'm afraid this bug is NOT FIXED. I've just tested with 3.13.0-123 (installed today via apt-get), and the system still hangs with it.

Joseph, I'm still willing and able to test more kernels.

[Rod Smith (rodsmith)]

This bug is ***NOT FIXED!*** I've just confirmed it still exists on two systems. Note that the bug is specific to the 3.13 kernel series (it does not affect 4.4 or other kernel series), and to the EFI stub loader (it doesn't manifest when using GRUB 2, for instance).