Default EFI install fails to boot on Lenovo T540p

[byron.hawkins]

Hi, I recently installed kubuntu with manual partition configuration on a system have no other OS. In the installer, I specified manual partitions and created an EFI partition at the start of the drive (200MB). There were two problems with the default EFI partition that was created:

1. The partition type was not set to "EFI System". I had to boot from liveUSB and change it with fdisk.
   
2. Grub was written to /boot/EFI/ubuntu/grubx64.efi. Please be aware that not all firmware will see this file! My new Lenovo T540p (arrived 2014-12-19 from the manufacturer) requires grubx64.efi to be copied to /boot/EFI/boot/bootx64.efi.

Before I fixed these problems, the system would not boot past BIOS, and gave no errors or warnings of any kind. Please consider updating the installer to (1) create the correct partition type for EFI partitions, and (2) duplicate the grub .cfg file as .../EFI/boot/bootx64.efi if no such file exists already (and maybe warn?overwrite if it does). It would have saved me 8 hours of totally wasted time. Thanks.

[SteveRiley]

To load anything other than /boot/EFI/boot/bootx64.efi, the bootloader must be declared in an EFI NVRAM variable. I suspect that this was missing. You can verify by running the command sudo efibootmgr -v. Here's the output from my T520:

steve@t520:~$ [B]sudo efibootmgr -v[/B]
BootCurrent: 0017
Timeout: 0 seconds
BootOrder: 0017,0006,000C,0007,000A,0008,000D,000E,000F,000B,0009,0011,0012,0010,0013
Boot0000  Setup FvFile(721c8b66-426c-4e86-8e99-3457c46ab0b9)
Boot0001  Boot Menu     FvFile(126a762d-5758-4fca-8531-201a7f57f850)
Boot0002  Diagnostic Splash Screen      FvFile(a7d8d9a6-6ab0-4aeb-ad9d-163e59a7a380)
Boot0003  Startup Interrupt Menu        FvFile(f46ee6f4-4785-43a3-923d-7f786c3c8479)
Boot0004  ME Configuration Menu FvFile(82988420-7467-4490-9059-feb448dd1963)
Boot0005  Rescue and Recovery   FvFile(665d3f60-ad3e-4cad-8e26-db46eee9f1b5)
Boot0006* USB CD        VenMsg(bc7838d2-0f82-4d60-8316-c068ee79d25b,86701296aa5a7848b66cd49dd3ba6a55)
Boot0007* USB FDD       VenMsg(bc7838d2-0f82-4d60-8316-c068ee79d25b,6ff015a28830b543a8b8641009461e49)
Boot0008* ATAPI CD0     VenMsg(bc7838d2-0f82-4d60-8316-c068ee79d25b,aea2090adfde214e8b3a5e471856a35401)
Boot0009  ATA HDD2      VenMsg(bc7838d2-0f82-4d60-8316-c068ee79d25b,91af625956449f41a7b91f4f892ab0f602)
Boot000A* ATA HDD0      VenMsg(bc7838d2-0f82-4d60-8316-c068ee79d25b,91af625956449f41a7b91f4f892ab0f600)
Boot000B  ATA HDD1      VenMsg(bc7838d2-0f82-4d60-8316-c068ee79d25b,91af625956449f41a7b91f4f892ab0f601)
Boot000C* USB HDD       VenMsg(bc7838d2-0f82-4d60-8316-c068ee79d25b,33e821aaaf33bc4789bd419f88c50803)
Boot000D* PCI LAN       VenMsg(bc7838d2-0f82-4d60-8316-c068ee79d25b,78a84aaf2b2afc4ea79cf5cc8f3d3803)
Boot000E  ATAPI CD1     VenMsg(bc7838d2-0f82-4d60-8316-c068ee79d25b,aea2090adfde214e8b3a5e471856a35403)
Boot000F  ATAPI CD2     VenMsg(bc7838d2-0f82-4d60-8316-c068ee79d25b,aea2090adfde214e8b3a5e471856a35404)
Boot0010  Other CD      VenMsg(bc7838d2-0f82-4d60-8316-c068ee79d25b,aea2090adfde214e8b3a5e471856a35406)
Boot0011  ATA HDD3      VenMsg(bc7838d2-0f82-4d60-8316-c068ee79d25b,91af625956449f41a7b91f4f892ab0f603)
Boot0012  ATA HDD4      VenMsg(bc7838d2-0f82-4d60-8316-c068ee79d25b,91af625956449f41a7b91f4f892ab0f604)
Boot0013  Other HDD     VenMsg(bc7838d2-0f82-4d60-8316-c068ee79d25b,91af625956449f41a7b91f4f892ab0f606)
Boot0014* IDER BOOT CDROM       ACPI(a0341d0,0)PCI(16,2)ATAPI(0,1,0)
Boot0015* IDER BOOT Floppy      ACPI(a0341d0,0)PCI(16,2)ATAPI(0,0,0)
Boot0016* ATA HDD       VenMsg(bc7838d2-0f82-4d60-8316-c068ee79d25b,91af625956449f41a7b91f4f892ab0f6)
Boot0017* rEFInd Boot Manager   HD(1,28,100000,35a3de7a-7015-4855-b882-1c8e9432b8fe)File(\EFI\refind\refind_x64.efi)
Boot0018* PCI LAN       VenMsg(bc7838d2-0f82-4d60-8316-c068ee79d25b,78a84aaf2b2afc4ea79cf5cc8f3d3803)

I'm using rEFInd, and you can see its bootloader entry in variable Boot0017. If I were using GRUB, there would be an NVRAM variable containing GRUB's EFI loader.

I've noticed you posted this message to the Raring forum. That release is over a year and half old. UEFI support has matured a lot since then; the current installer solves both problems you're reporting here. It correctly marks the EFI system partition and it correctly creates the necessary NVRAM variable.

[byron.hawkins]

I'm using rEFInd, and you can see its bootloader entry in variable Boot0017. If I were using GRUB, there would be an NVRAM variable containing GRUB's EFI loader.

Yes, this is missing in my install.

I've noticed you posted this message to the Raring forum. That release is over a year and half old. UEFI support has matured a lot since then; the current installer solves both problems you're reporting here. It correctly marks the EFI system partition and it correctly creates the necessary NVRAM variable.

Just yesterday I installed the very latest Kubuntu 14.10 from here: http://www.kubuntu.org/getkubuntu. So the latest installer is not solving these problems for manual partitions. I asked the installer to make an EFI partition, and it made a half-configured EFI partition that failed to boot. It seems like a bug to me.

[SteveRiley]

Hmm... I've previously installed the 14.04 ISO in the exact same scenario you describe: clean system, no OS. All the UEFI setup worked as expected. If 14.10 isn't working, a regression bug must have appeared. I'll test it later on my T520 with a spare hard drive when I return home from a concert this evening.

[SteveRiley]

NOTE: thread moved to 14.10 as problem is reported in that release also.

[byron.hawkins]

Hmm... I've previously installed the 14.04 ISO in the exact same scenario you describe: clean system, no OS. All the UEFI setup worked as expected. If 14.10 isn't working, a regression bug must have appeared. I'll test it later on my T520 with a spare hard drive when I return home from a concert this evening.

Much appreciated. If it turns out I just did something wrong, let me know--I'll try to figure out what it was and post here, in case anyone else does the same thing. I'm definitely no expert in Linux, though I have installed it about 10 times without having this particular issue.

[SteveRiley]

Alrighty, I just finished the experiment.

After installing, here are the EFI variables:

BootCurrent: 0017
Timeout: 0 seconds
BootOrder: 0017,0017,0006,000C,0007,000A,0008,000D,000E,000F,000B,0009,0011,0012,0010,0013
Boot0000  Setup	FvFile(721c8b66-426c-4e86-8e99-3457c46ab0b9)
Boot0001  Boot Menu	FvFile(126a762d-5758-4fca-8531-201a7f57f850)
Boot0002  Diagnostic Splash Screen	FvFile(a7d8d9a6-6ab0-4aeb-ad9d-163e59a7a380)
Boot0003  Startup Interrupt Menu	FvFile(f46ee6f4-4785-43a3-923d-7f786c3c8479)
Boot0004  ME Configuration Menu	FvFile(82988420-7467-4490-9059-feb448dd1963)
Boot0005  Rescue and Recovery	FvFile(665d3f60-ad3e-4cad-8e26-db46eee9f1b5)
Boot0006* USB CD	VenMsg(bc7838d2-0f82-4d60-8316-c068ee79d25b,86701296aa5a7848b66cd49dd3ba6a55)
Boot0007* USB FDD	VenMsg(bc7838d2-0f82-4d60-8316-c068ee79d25b,6ff015a28830b543a8b8641009461e49)
Boot0008* ATAPI CD0	VenMsg(bc7838d2-0f82-4d60-8316-c068ee79d25b,aea2090adfde214e8b3a5e471856a35401)
Boot0009  ATA HDD2	VenMsg(bc7838d2-0f82-4d60-8316-c068ee79d25b,91af625956449f41a7b91f4f892ab0f602)
Boot000A* ATA HDD0	VenMsg(bc7838d2-0f82-4d60-8316-c068ee79d25b,91af625956449f41a7b91f4f892ab0f600)
Boot000B  ATA HDD1	VenMsg(bc7838d2-0f82-4d60-8316-c068ee79d25b,91af625956449f41a7b91f4f892ab0f601)
Boot000C* USB HDD	VenMsg(bc7838d2-0f82-4d60-8316-c068ee79d25b,33e821aaaf33bc4789bd419f88c50803)
Boot000D* PCI LAN	VenMsg(bc7838d2-0f82-4d60-8316-c068ee79d25b,78a84aaf2b2afc4ea79cf5cc8f3d3803)
Boot000E  ATAPI CD1	VenMsg(bc7838d2-0f82-4d60-8316-c068ee79d25b,aea2090adfde214e8b3a5e471856a35403)
Boot000F  ATAPI CD2	VenMsg(bc7838d2-0f82-4d60-8316-c068ee79d25b,aea2090adfde214e8b3a5e471856a35404)
Boot0010  Other CD	VenMsg(bc7838d2-0f82-4d60-8316-c068ee79d25b,aea2090adfde214e8b3a5e471856a35406)
Boot0011  ATA HDD3	VenMsg(bc7838d2-0f82-4d60-8316-c068ee79d25b,91af625956449f41a7b91f4f892ab0f603)
Boot0012  ATA HDD4	VenMsg(bc7838d2-0f82-4d60-8316-c068ee79d25b,91af625956449f41a7b91f4f892ab0f604)
Boot0013  Other HDD	VenMsg(bc7838d2-0f82-4d60-8316-c068ee79d25b,91af625956449f41a7b91f4f892ab0f606)
Boot0014* IDER BOOT CDROM	ACPI(a0341d0,0)PCI(16,2)ATAPI(0,1,0)
Boot0015* IDER BOOT Floppy	ACPI(a0341d0,0)PCI(16,2)ATAPI(0,0,0)
Boot0016* ATA HDD	VenMsg(bc7838d2-0f82-4d60-8316-c068ee79d25b,91af625956449f41a7b91f4f892ab0f6)
[B][COLOR="#B22222"]Boot0017* ubuntu	HD(1,800,100000,953249ff-425b-416b-a938-d2b7321584d2)File(\EFI\ubuntu\shimx64.efi)[/COLOR][/B]
Boot0018* PCI LAN	VenMsg(bc7838d2-0f82-4d60-8316-c068ee79d25b,78a84aaf2b2afc4ea79cf5cc8f3d3803)

Because *buntu now fully supports Secure Boot, it will actually start the shim loader. This is used for managing Secure Boot signed images without having to go through Microsoft. In situations where Secure Boot is disabled, shim simply passes control to grubx64.efi and does nothing else.

Annoyingly, the installer deleted my existing EFI variable. One the one hand, maybe that makes sense: the disk it pointed to no longer existed in the system, so why not delete it? On the other hand, this would completely flummox anyone unfamiliar with EFI who did the same thing here -- put a tempoarary disk in, experiment, then return the original disk. The EFI variable for the partition on your original disk would be gone! You have to know enough about UEFI to boot a USB and then re-create the variable. Here's what I did:

sudo efibootmgr -c -d /dev/sda -p 1 -l "\EFI\refind\refind_x64.efi" -L "rEFInd Boot Manager"

Here are the disk partitions:

GPT fdisk (gdisk) version 0.8.8

Partition table scan:
  MBR: protective
  BSD: not present
  APM: not present
  GPT: present

Found valid GPT with protective MBR; using GPT.
Disk /dev/sda: 250069680 sectors, 119.2 GiB
Logical sector size: 512 bytes
Disk identifier (GUID): FFD680DC-7B8E-4C1D-9BFA-A8BA3DFECDC1
Partition table holds up to 128 entries
First usable sector is 34, last usable sector is 250069646
Partitions will be aligned on 2048-sector boundaries
Total free space is 2669 sectors (1.3 MiB)

Number  Start (sector)    End (sector)  Size       Code  Name
[B][COLOR="#B22222"]   1            2048         1050623   512.0 MiB   8300[/COLOR][/B]  
   2         1050624       233531391   110.9 GiB   8300  
   3       233531392       250068991   7.9 GiB     8200

The EFI system partition should be labeled EF00, for "EFI System." But instead it's labeled 8300, for "Linux filesystem." (You can see a list of types and codes when you run gdisk and press l.)

Actually, though, this doesn't matter. UEFI isn't looking for partition codes. Instead, it's looking for a particular GUID: C12A7328-F81F-11D2-BA4B-00A0C93EC93B. That is the reserved GUID for the EFI system partition. And indeed we can see that it is:

GPT fdisk (gdisk) version 0.8.8

Partition table scan:
  MBR: protective
  BSD: not present
  APM: not present
  GPT: present

Found valid GPT with protective MBR; using GPT.

Command (? for help): i
Partition number (1-3): 1
[B][COLOR="#B22222"]Partition GUID code: C12A7328-F81F-11D2-BA4B-00A0C93EC93B (EFI System)[/COLOR][/B]
Partition unique GUID: 35A3DE7A-7015-4855-B882-1C8E9432B8FE
First sector: 2048 (at 1024.0 KiB)
Last sector: 1050623 (at 513.0 MiB)
Partition size: 1048576 sectors (512.0 MiB)
Attribute flags: 0000000000000000
Partition name: ''

Looking at /etc/fstab, we can see that the partition has a FAT file system, which is really the only requirement other requirement besides the correct GUID:

# /etc/fstab: static file system information.
#
# Use 'blkid' to print the universally unique identifier for a
# device; this may be used with UUID= as a more robust way to name devices
# that works even if disks are added and removed. See fstab(5).
#
# <file system> <mount point>   <type>  <options>       <dump>  <pass>
# / was on /dev/sda2 during installation
UUID=a60da7cd-613e-441c-86ed-b8f40515186d /               ext4    errors=remount-ro 0       1
[B][COLOR="#B22222"]# /boot/efi was on /dev/sda1 during installation
UUID=50AA-7F83  /boot/efi       vfat    defaults        0       1[/COLOR][/B]
# swap was on /dev/sda3 during installation
UUID=f93c4dc7-ca23-48e2-9edf-ce061025e882 none            swap    sw              0       0

And lsblk verifies the proper mount point:

NAME   MAJ:MIN RM   SIZE RO TYPE MOUNTPOINT
sda      8:0    0 119.2G  0 disk 
[B][COLOR="#B22222"]├─sda1   8:1    0   512M  0 part /boot/efi[/COLOR][/B]
├─sda2   8:2    0 110.9G  0 part /
└─sda3   8:3    0   7.9G  0 part [SWAP]

Let's examine what's in the EFI system partition:

/boot/efi/EFI:
total 12
drwxrwxrwx 3 root root 4096 Dec 22  2014 .
drwxrwxrwx 3 root root 4096 Dec 31  1969 ..
drwxrwxrwx 2 root root 4096 Dec 22  2014 ubuntu

/boot/efi/EFI/ubuntu:
total 3432
drwxrwxrwx 2 root root    4096 Dec 22  2014 .
drwxrwxrwx 3 root root    4096 Dec 22  2014 ..
-rwxrwxrwx 1 root root     126 Dec 22  2014 grub.cfg
-rwxrwxrwx 1 root root  957816 Dec 22  2014 grubx64.efi
-rwxrwxrwx 1 root root 1264848 Dec 22  2014 MokManager.efi
-rwxrwxrwx 1 root root 1276984 Dec 22  2014 shimx64.efi

Looks normal.

In early 2013, the kernel became very conservative about updating NVRAM variables because certain Samsung implementions would brick themselves if total NVRAM storage space exceeded 50%. This eventually got fixed (Launchpad bug 1173423) in some Raring kernels, and in all kernels in subsequent releases. So if you were trying a release from around that time, this could explain the lack of an EFI variable.

But with 14.10, I was unable to duplicate your situation on my machine. I even performed it twice just to be sure. Thus, I don't have an explanation for the behavior you saw.

[byron.hawkins]

Wow, thanks for the info, that's tremendously helpful for next time I need to install an EFI boot. Actually I have a dual boot machine where Windows is UEFI and Linux is BIOS, so I think this gives me enough info to fix it (make them both UEFI) without breaking the Linux install.

Is there a way I can quickly repeat my install process to see what may have happened to the EFI variable, without going through a whole *buntu install? I have a blank disk to use in my Lenovo. Since there's already some time invested in the matter, it would be nice to find out what exactly happened, since I don't recall doing anything special or unusual.

[SteveRiley]

I wrote a step-by-step guide for setting up dual-boot with Windows 8.1 and Kubuntu. It starts from the very beginning. I wiped my ThinkPad X1 completely, installed Windows 8.1, made some changes, then installed Kubuntu. The post has a lot of detail -- after each step, I investigated how the installers created partitions and configured the firmware. You can follow that guide on a machine that already has Windows 8.1 installed. Start with "Part 3, Necessary Windows configuration procedures." But take a look at the first post in the thread for the initial assumptions and machine state I operated with.

[justlinux]

Creating the boot directory and renaming grubx64.efi and copying it and grub.cfg over to the boot directory let's me start correctly from virtualbox now without having to manually go in and start grubx64.efi on the new Kubuntu Plasma-5 version. Thanks for the tip, I didn't have to do anything partition wise but now this is a lot better.