Steve's blog
   


Steve About
Steve's blog,
The Words of the Sledge
steve@einval.com

Subscribe
Subscribe to the RSS feed.

Links

  • Home
  • Debian
  • PlanetDebian
  • Search PlanetDebian
  • Friends

  • Matthew Garrett
  • Jonathan McDowell
  • Jo McIntyre
  • Martin Michlmayr
  • Andrew Mobbs
  • Mike Pitt
  • Daniel Silverstone
  • Andy Simpkins
  • Neil Williams

  •        

    Sunday, 02 August 2015

    Tracking broken UEFI implementations

    There can be issues with shipping installer images including UEFI. But they're mainly due to crappy UEFI implementations that vendors have shipped. It's fairly well-known that Apple have shipped some really shoddy firmware over the years, and to allow people to install Debian on older Apple x86 machines we've now added the workaround of a non-UEFI 32-bit installer image too. But Apple aren't the only folks shipping systems with horrendously buggy UEFI, and a lot of Linux folks have had to deal with this over the last few years.

    I've been talking to a number of other UEFI developers lately, and we've agreed to start a cross-distro resource to help here - a list of known-broken UEFI implementations so that we can share our experiences. The place for this in in the OSDev wiki at http://wiki.osdev.org/Broken_UEFI_implementations. We're going to be adding new information here as we find it. If you've got a particular UEFI horror story on your own broken system, then please either add details there or let me know and I'll try to do it for you.

    00:40 :: # :: /debian/efi :: 3 comments

    Comments

    Re: Tracking broken UEFI implementations
    GreatEmerald wrote on Fri, 07 Aug 2015 13:44

    There's a similar issue as what Holzhaus described in my HP 2000 laptop, though not as severe.

    Basically, the UEFI is broken in two ways: 1) It always creates, in Boot0000 slot, an entry to boot either EFI/Microsoft/Boot/bootmgfw.efi or EFI/Boot/bootx64.efi, in that order, if those files exist; 2) It ignores the BootOrder variable and boots in variable order, from Boot0000 to Boot0001 to Boot0002 to Boot1001 etc.

    The best way to boot that is to make sure neither of the two files exist, and create a boot entry Boot0001 pointing to GRUB or whatnot.

    Of course, then booting Windows is a bit of a problem. You need to change BCD settings to point to the new Windows EFI file name, and/or change GRUB settings to detect the new Windows filename. The GRUB os-prober is annoying in that it, too, simply checks for EFI/Microsoft/Boot/bootmgfw.efi and gives up if it's not there.


    Reply

    Your Comment

     
    Name:
    URL/Email: [http://... or mailto:you@wherever] (optional)
    Title: (optional)
    Comment:
    Anti-spam:Select the seventh of the following words and enter it in the "Human" box
    pick pooched pinups prefixed pomaded petted prefers produce parches pinky
    Human:
    Save my Name and URL/Email for next time