Re: UEFI works with USB but not with HDD
On Fri, Jun 26, 2015 at 7:23 PM, Steve McIntyre <steve@einval.com> wrote:
>>Hi Steve,
>>As you suggested I use the option "Force Grub installation to the EFI
>>removable media path" and it works :)
>
> OK, cool.
>
>>Is there any disadvantage using this option? What is the difference
>>between this option and the regular UEFI boot?
>
> The main disadvantage with this is that different OS installers will
> fight each other to install to this location, just like the old BIOS
> MBR boot block problem. That *shouldn't* cause you any problems,
> unless you've got other operating systems on your hard disk that
> os-prober hasn't found and added to the grub menu for you. That code
> should work anyway, and give you boot options for any other OSes. If
> you're not dual-booting then this can't be an issue.
>
> Regular UEFI boot has several lists of possible boot entries, stored
> in UEFI config variables (normally in NVRAM), and boot order config
> variables stored alongside them. It allows for many different boot
> options, and a properly-defined fallback order. In many cases, you can
> even list and choose which OS / boot loader to use from the system
> boot menu (similar to the boot device menu implemented in many
> BIOSes). Unfortunately, a lot of UEFI implementations have got this
> wrong and so don't work properly.
>
> The correct way for this to work when booting off local disk is for a
> boot variable to point to a vendor-specific bootloader program in
>
> \EFI\$vendor\$bootloader.efi
>
> on the EFI System Partition (ESP). You'll see that Debian installs
> grub as \EFI\debian\grubx64.efi for its EFI bootloader; grubx64.efi
> contains all the bits that grub needs to work from that point. By
> using separate vendor directories like this, EFI allows for clean
> interoperability between vendors. If only the firmware developers were
> competent... :-( Some implementations ignore the boot order
> altogether, some filter it and will only run things that claim to be
> "Windows", etc.
>
> Because of this incompetence, the Windows installer *also* installs to
> the removable media path in the ESP (e.g. \EFI\boot\bootx64.efi for
> amd64/X64 systems). *All* implentations have to use this path to be
> able to run an OS installer. This means that Windows will always work
> on all these broken implementations, but it also means that system
> vendors can get away with shipping broken implementations. It removes
> the idea of having a fallback boot path and sensible control of boot
> order.
>
> All OS installers installing things to this removable media path will
> therefore conflict with any other such installers, which is bad and
> wrong. That's why in Debian we *don't* do this by default and only
> make this available as an option for people that need it, in the
> rescue mode code you've just used.
>
> Hope that helps!
>
Thanks a lot for the great explanation!
I think it would be helpful for other users to put all this in the
Debian Wiki. Maybe you can paste your answer in a new entry in
https://wiki.debian.org/BootLoader , such as Installing Debian in a
Buggy UEFI Implementation.
Best,
Dani
Reply to: