grub-efi grub.cfg generated with incorrect commands, linux and initrd, instead of linuxefi and initrdefi

[David Ball]

grub.cfg is generated with incorrect commands, linux and initrd, instead of linuxefi and initrdefi. This affects both the install .iso for the latest Ubuntu 13.10 and the installed system of the latest Ubuntu 13.10.

Simple Workaround:

You can hand-edit the commands in grub to boot the target system. Once inside, then you can edit /boot/grub/grub.cfg to change all linux and initrd commands to linuxefi and initrdefi, respectively. This will have to be updated each time the grub.cfg file is regenerated, i.e., whenever new kernels are updated.

Configuration Patch (Proposed Fix, Untested):

Then to ensure grub.cfg is regenerated correctly, edit /etc/grub.d/10_linux so that

line 166 says linuxefi instead of linux

and

line 182 says initrdefi instead of initrd

But line 182 probably needs to be updated to include encapsulating code that tests for efi just like on lines 164-172 via an:

if test -d /sys/firmware/efi && test -e "${linux}.efi.signed"; then (...use initrdefi) else (...use initrd) ... fi.

Thanks!
David

ProblemType: Bug
DistroRelease: Ubuntu 13.10
Package: grub-efi (not installed)
ProcVersionSignature: Ubuntu 3.11.0-12.19-generic 3.11.3
Uname: Linux 3.11.0-12-generic x86_64
ApportVersion: 2.12.5-0ubuntu2.1
Architecture: amd64
Date: Sun Oct 27 06:13:32 2013
InstallationDate: Installed on 2013-10-27 (0 days ago)
InstallationMedia: Ubuntu 13.10 "Saucy Salamander" - Release amd64 (20131016.1)
MarkForUpload: True
SourcePackage: grub2
UpgradeStatus: No upgrade log present (probably fresh install)

[Phillip Susi (psusi)]

What? There shouldn't be a special version of the command for efi; the regular linux and initrd commands should work just fine.

[David Ball (s07kw)]

I'm not sure Phillip. I know that I have a UEFI BIOS on my ASUS K55N notebook, and that when booting using BIOS mode (select a disk from the list and boot the MBR) the regular linux and initrd commands work just fine. That was how I was using Fedora 19 until two days ago. I switched my disk from MBR to GPT and placed an EFI partition outside the LVM prior to installing Ubuntu 13.10.

I encountered issues booting the ISO from the USB disk right off the rip. When the USB/DVD boots through UEFI, which is the way the ASUS K55N BIOS prefers to boot the USB/DVD, it launches GRUB instead of the ISOLINUX/SYSLINUX boot loader. Any of the options I select will not boot the Live ISO environment. It seems the ISO is broken.

So, curious as I am, checked the commands that GRUB uses to boot the ISO. There were 3 problems that I found.

linux instead of linuxefi
invalid kernel path at /cdrom/preseed/ubuntu.seed, should be /preseed/ubuntu.seed
initrd instead of initrdefi

So inside the ISO:/boot/grub.cfg, the transform is from:

menuentry "Try Ubuntu without installing" {
 set gfxpayload=keep
 linux /casper/vmlinuz.efi file=/cdrom/preseed/ubuntu.seed boot=casper quiet splash --
 initrd /casper/initrd.lz
}

to:ne

menuentry "Try Ubuntu without installing" {
 set gfxpayload=keep
 linuxefi /casper/vmlinuz.efi file=/preseed/ubuntu.seed boot=casper quiet splash --
 initrdefi /casper/initrd.lz
}

and so on for each of the entries.

Once inside the live environment, I was able to install Ubuntu 13.10 without any issues, using an LVM setup with seperate /home, /boot (outside the LVM), and an EFI partition. Everything worked perfectly. Reboot. Purple screen forever.

Forced the power off, grub noticed it didn't boot, and prompted me with the menu. I inspected the command list and found similar issues. I documented the changes I made in the original post, and I was able to boot into the system just fine. I made the grub.cfg change and updated the /etc/grub.d/10_linux script as well, and the system works flawlessly now.

It may or may not be related to Secure Boot, but I do not have an option to enable/disable Secure Boot with this BIOS. The initrdefi and linuxefi commands apparently have no documentation, but they do exist and they do permit my system to boot Ubuntu only when they are enabled.

I look forward to further input about the issue, but this is my individual experience. Thanks again! If you need any more info, let me know.

[David Ball (s07kw)]

I installed the x64 Shell.efi version 2.0 into /boot/efi/Shellx64.efi and instructed my BIOS to launch the shell so I could poke around a little bit.

When I boot fs0:/EFI/ubuntu/grubx64.efi, Ubuntu will not boot from my hard drive, saying /vmlinuz-...-generic.efi.signed has invalid signature, you need to load the kernel first.

When I boot fs0:/EFI/ubuntu/shimx64.efi, Ubuntu boots just fine using the one and the same grub that booted from grubx64.efi.

I am still trying to wrap my head around all the implications of UEFI, but this is perhaps indicative of booting Ubuntu using Secure Boot.

Since almost none of this is documented anywhere, and my BIOS is very limited, I can't be sure of anything I'm looking at. I'm not sure what the shimx64.efi is nor why seperate commands are required in GRUB in order to boot linux using EFI, but it is probably all directly related to UEFI Secure Boot.

[Phillip Susi (psusi)]

Yes, it sounds like the secure boot junk added these new commands and it really should not have done that. It should just modify the existing commands to handle the signature verification.

[Colin Watson (cjwatson)]

The secure boot patches in Ubuntu *do* modify linux and initrd to call linuxefi and initrdefi as necessary. It is absolutely incorrect to change grub.cfg to use linuxefi and initrdefi.

[Steve Langasek (vorlon)]

As Colin says, you're not supposed to use a different 'linuxefi' command here. So the bug as described is invalid.

If you think there's still a bug here, please restate the problem in terms of the wrong behavior seen when using *stock* Ubuntu boot configs.