mjg59 | More in the series of bizarre UEFI bugs

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…

Flat | Top-Level Comments Only

What option do we have, how can we address that as a community?

Maybe annnoying/DDoSing the sloppy vendor with all the different variations of things they broke with that helpful check (like, "I've tried these Linux distributions: [liiiist] and not a single one [but RHEL] worked after successful installation in UEFI mode while all of these work on an [HP/SONY/ASUS item]")...

That takes hardware and patience though, no use to cheat.

--
Michael Shigorin

Yeah, that's not a solution.

How is being 14? It was so long ago I don't remember.

It looks like Lenovo have noticed, so perhaps they'll fix it.

Many people will not be able to return their hardware if it does not
work with anything else than one operating system and the manufacturer
did not clearly state that; or a BIOS upgrade cripples all installed
OSes except for one. Legal counsel would be helpful, even if it just
consists of publicly given instructions. The BIOS upgrade case
potentially can be intentional damage to already purchased hardware,
or whatever the lawyers call that.

At least these were the thoughts that passed through my head when I was
choosing to buy some piece of dont-know-what with Win 8 logo,
and it also pushed me many years back to times when I was checking
if the hardware has linux drivers at all.

In the EU its easy - return it as unfit for the purpose for which it was sold - the firmware is buggy.

But above all and with all the UEFI secure boot sh*t - phone the company, email them make their tech support costs go up. Their margins are so low that if even a few of the people who can't get old Windows, Linux etc running on the box keeps phoning and complaining they'll make a loss on the product line.

Phoning a company to make their support cost go up might not work that well if they do not publish freecall numbers, which they usually don't. Instead, calling them actually makes them more money.

The numbers that make them money always have a real geographic number behind them. And quite a few mobile plans include free landline calls anywhere in $COUNTRY.

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.

More in the series of bizarre UEFI bugs

Plan of action

Re: Plan of action

Re: Plan of action

Re: Plan of action

Re: Plan of action

Re: Plan of action

Re: Plan of action

driving up revenue

Re: driving up revenue

Re: Plan of action