4 ms·

Unless you're doing something super screwy, GRUB, the excuse for this backwards default, doesn't even need access to UEFI. UEFI booting looks for a file in a FA

Unless you're doing something super screwy, GRUB, the excuse for this backwards default, doesn't even need access to UEFI. UEFI booting looks for a file in a FAT-formatted partition of a hard disk with a specific ID -- C12A7328-F81F-11D2-BA4B-00A0C93EC93B for GPT disks and 0xEF for MBR disks. All EFI does is to look for a file BOOTX64.EFI on that partition. There's no need to muck around the UEFI settings for this, it Just Fucking Works.

JoshTriplett 11y ago
Only removable disks use bootx64.efi, though some (but not all) BIOSes will look for that on fixed disks too. efibootmgr needs access to efivarsfs to configure an EFI boot entry for Linux on a fixed disk. Relying exclusively on bootx64.efi on the EFI system partition will break on some devices, and will overwrite the Windows bootloader (and conversely, Windows doing so will render Linux unbootable).
- Sanddancer 11y ago
  The standard is for EFI to look for that partition on all disks, even hard disks. If there are a few broken systems that do otherwise, they could use other methods, but keeping things mostly standardized seems like the best way to go. It's how Windows does it, it's how FreeBSD does it, it's how OpenBSD does it, etc. Mucking around with it doing otherwise is just asking for problems.
  - JoshTriplett 11y ago
    The EFI standard specifically limits that to removable media. Windows installs itself via the EFI boot variable mechanism; Windows also installs itself to bootx64.efi, but even if you overwrite that, you can still boot Windows via its EFI boot entry. Having Linux systems install themselves only to bootx64.efi would produce a fragile installation (particularly in dual-boot configurations).
    - Sanddancer 11y ago
      Okay, I read the standard and you're right, they are supposed to install to a vendor specific location, so my apologies. Boot's an additional place you can put it, but not the regular place. As an aside, goddamn is UEFI ugly. BIOS it was easy -- set the partition you want to boot as bootable, and away you go. here you have to copy the bootloader file, and then write to the firmware what file you want to boot, which feels even more fragile and confusing if you decide to wipe a hard drive to put a new OS on it unless you do everything just right.
      - simoncion 11y ago
        > As an aside, goddamn is UEFI ugly. You're goddamn right it is. Matthew Garrett [0] used to do UEFI stuff for -IIRC- RedHat. He has MANY blog posts about fucked-up parts of the spec, and horrifyingly fucked-up implementations of the same. Sadly, it looks like most (if not all) of his posts are now tagged "advogato, fedora", so I can't point you specifically to the UEFI gore posts. [0] http://mjg59.dreamwidth.org/ http://mjg59.dreamwidth.org/
        yuhong 11y ago
        My personal favorite is how http://lkml.org/lkml/2013/11/11/653 http://lkml.org/lkml/2013/11/11/653 is posted by @hp.com that also locked access to UEFI updates to paid customers not long after it was posted.
      - JoshTriplett 11y ago
        At least in theory, UEFI intended to avoid the current problem of OS bootloaders taking over (by writing to the MBR) and then needing to know how to boot other OSes. (Or, in practice, Linux bootloaders knowing how to boot everything and all other bootloaders only booting their own OS.) If you install your bootloader via the standard UEFI mechanism, you won't step on any other OS on the same system. And at boot time, you get a menu of OSes, with labels provided by those OSes. The problem comes in with the small handful of UEFI firmware implementations that get EFI variables so horribly wrong that attempting to write to them in the standard way will cause the EFI firmware to overwrite itself or otherwise brick the machine. Linux does attempt to work around some of those systems through very careful handling of EFI variable writes.

JoshTriplett 11y ago

Only removable disks use bootx64.efi, though some (but not all) BIOSes will look for that on fixed disks too. efibootmgr needs access to efivarsfs to configure an EFI boot entry for Linux on a fixed disk. Relying exclusively on bootx64.efi on the EFI system partition will break on some devices, and will overwrite the Windows bootloader (and conversely, Windows doing so will render Linux unbootable).

Sanddancer 11y ago
The standard is for EFI to look for that partition on all disks, even hard disks. If there are a few broken systems that do otherwise, they could use other methods, but keeping things mostly standardized seems like the best way to go. It's how Windows does it, it's how FreeBSD does it, it's how OpenBSD does it, etc. Mucking around with it doing otherwise is just asking for problems.
- JoshTriplett 11y ago
  The EFI standard specifically limits that to removable media. Windows installs itself via the EFI boot variable mechanism; Windows also installs itself to bootx64.efi, but even if you overwrite that, you can still boot Windows via its EFI boot entry. Having Linux systems install themselves only to bootx64.efi would produce a fragile installation (particularly in dual-boot configurations).
  - Sanddancer 11y ago
    Okay, I read the standard and you're right, they are supposed to install to a vendor specific location, so my apologies. Boot's an additional place you can put it, but not the regular place. As an aside, goddamn is UEFI ugly. BIOS it was easy -- set the partition you want to boot as bootable, and away you go. here you have to copy the bootloader file, and then write to the firmware what file you want to boot, which feels even more fragile and confusing if you decide to wipe a hard drive to put a new OS on it unless you do everything just right.
    - simoncion 11y ago
      > As an aside, goddamn is UEFI ugly. You're goddamn right it is. Matthew Garrett [0] used to do UEFI stuff for -IIRC- RedHat. He has MANY blog posts about fucked-up parts of the spec, and horrifyingly fucked-up implementations of the same. Sadly, it looks like most (if not all) of his posts are now tagged "advogato, fedora", so I can't point you specifically to the UEFI gore posts. [0] http://mjg59.dreamwidth.org/ http://mjg59.dreamwidth.org/
      - yuhong 11y ago
        My personal favorite is how http://lkml.org/lkml/2013/11/11/653 http://lkml.org/lkml/2013/11/11/653 is posted by @hp.com that also locked access to UEFI updates to paid customers not long after it was posted.
    - JoshTriplett 11y ago
      At least in theory, UEFI intended to avoid the current problem of OS bootloaders taking over (by writing to the MBR) and then needing to know how to boot other OSes. (Or, in practice, Linux bootloaders knowing how to boot everything and all other bootloaders only booting their own OS.) If you install your bootloader via the standard UEFI mechanism, you won't step on any other OS on the same system. And at boot time, you get a menu of OSes, with labels provided by those OSes. The problem comes in with the small handful of UEFI firmware implementations that get EFI variables so horribly wrong that attempting to write to them in the standard way will cause the EFI firmware to overwrite itself or otherwise brick the machine. Linux does attempt to work around some of those systems through very careful handling of EFI variable writes.