[personal profile] mjg59
A (well, now former) coworker let me know about a problem he was having with a Lenovo Thinkcentre M92p. It booted Fedora UEFI install media fine, but after an apparently successful installation refused to boot. UEFI installs on Windows worked perfectly. Secure Boot was quickly ruled out, but this could still have been a number of things. The most interesting observation was that the Fedora boot option didn't appear in the firmware boot menu at all, but Windows did. We spent a little while comparing the variable contents, gradually ruling out potential issues - Linux was writing an entry that had an extra 6 bytes in a structure, for instance[1], and a sufficiently paranoid firmware implementation may have been tripping up on that. Fixing that didn't help, though. Finally we tried just taking the Windows entry and changing the descriptive string. And it broke.

Every UEFI boot entry has a descriptive string. This is used by the firmware when it's presenting a menu to users - instead of "Hard drive 0" and "USB drive 3", the firmware can list "Windows Boot Manager" and "Fedora Linux". There's no reason at all for the firmware to be parsing these strings. But the evidence seemed pretty strong - given two identical boot entries, one saying "Windows Boot Manager" and one not, only the first would work. At this point I downloaded a copy of the firmware and started poking at it. Turns out that yes, actually, there is a function that compares the descriptive string against "Windows Boot Manager" and appears to return an error if it doesn't match. What's stranger is that it also checks for "Red Hat Enterprise Linux" and lets that one work as well.

This is, obviously, bizarre. A vendor appears to have actually written additional code to check whether an OS claims to be Windows before it'll let it boot. Someone then presumably tested booting RHEL on it and discovered that it didn't work. Rather than take out that check, they then addded another check to let RHEL boot as well. We haven't yet verified whether this is an absolute string match or whether a prefix of "Red Hat Enterprise Linux" is sufficient, and further examination of the code may reveal further workarounds. For now, if you want to run Fedora[2] on these systems you're probably best off changing the firmware to perform a legacy boot.

[1] src/include/efi.h: uint8_t padding[6]; /* Emperically needed */, says the efibootmgr source code. Unhelpful.
[2] Or Ubuntu, or Suse, or…

Re: Plan of action

Date: 2013-02-24 10:16 pm (UTC)
From: (Anonymous)
An issue I ran into on a Lenovo H430 desktop is that while the hard drive has Windows 8 pre-installed in UEFI mode, the DVD drive boots only in legacy mode, with no option to change it to UEFI mode.

Apparently the Ubuntu installer installs Ubuntu in the same mode in which it was booted. So even though I thought I was installing in UEFI mode, I wasn't. After tearing my hair out for two days, I decided to change the boot option on the machine to UEFI only and then the LiveDVD no longer booted. It was then that I realized what was going on and made a USB boot device since the USB ports boot in UEFI mode. Then I could do a UEFI install on second hard drive, with GPT partitioning. Linux would still not boot after the apparently successful install, but BootRepair fixed whatever was causing the problem. Next I had to get Windows 8 to also boot. the Grub OS-prober did not see the EFI boot partition. Manually adding an entry to 40_custom, then running Grub Customizer solved the Grub issue.

If I were able to give feedback to those that write the Ubuntu installer it would be this:

1. If possible, give the user an option of installing in UEFI mode with GPT even if the Live DVD boots in legacy mode. However there may be reasons that this is impossible, I don't know.

2. Make it clear if the installation is occurring in UEFI or Legacy mode--I thought I was installing in UEFI mode but I wasn't, until I switched to a UEFI USB stick from the Live DVD.

3. Have the installer do a sanity check on the partitions on a GPT partitioned drive. It's possible that the reason Boot Repair was needed is that there was a problem with the GPT partitions.

You're supposed to have an unformatted partition at the beginning of the drive with the bios_grub flag set ("In GParted, create a partition (an unformatted one works fine), then right-click it and select Manage Flags. Check the bios_grub flag, click Close, and apply your changes"), but I could not get gparted to set a flag on an unformatted partition. I formatted it to FAT16 based on the advice of someone else that ran into this issue. this appeared to work, but now when I run gparted the partition with the bios_grub flag set has a red exclamation point and gparted gives a warning that it can't read the contents of that file system.

4. Figure out why Boot Repair is needed after a UEFI install--I don't think it should be but it was. It must be related to how the partitions are set up.

Profile

Matthew Garrett

About Matthew

Power management, mobile and firmware developer on Linux. Security developer at Nebula. Member of the Linux Foundation Technical Advisory Board. Ex-biologist. @mjg59 on Twitter. Content here should not be interpreted as the opinion of my employer.

Page Summary

Expand Cut Tags

No cut tags