As previously expressed; we probably *shouldn't* ship EFI/Boot/bootx64.efi; but since Windows often does, there might be no way around it.
Firmwares are supposed to follow the BootEntries to know what path to use for booting (ie. we create "ubuntu", which points to \EFI\ubuntu\shimx64.efi). If these entries don't exist, firmware will attempt to use the default paths from \EFI\Boot. Fortunately, shim comes with a fallback.efi binary. One option to fix this (see [1]) would be to write a bootx64.efi to \EFI\Boot which contains our shim (and other operating systems would do the same), along with fallback.efi. The fallback.efi program will walk through the tree searching for boot.csv files (which is another file we'll need to write) for the details on how to rebuild boot entries, then it will attempt to boot the first entry added. I haven't tested this at all, and I'm a little bit worried about what might happen for really broken firmware where the entries are still there, but ignored somehow -- I'd like to make sure that fallback.efi does the right thing in this case. [1] https://blog.uncooperative.org/blog/2014/02/06/the-efi-system- partition/ ** Changed in: ubiquity (Ubuntu) Status: Confirmed => Invalid ** Changed in: grub2 (Ubuntu) Status: Confirmed => Invalid ** Changed in: shim (Ubuntu) Status: Confirmed => Triaged -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/1366546 Title: Ubuntu doesn't provide \EFI\BOOT\BOOTX64.EFI for UEFI systems To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/grub2/+bug/1366546/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
