On Fri, Jun 26, 2015 at 7:23 PM, Steve McIntyre <st...@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 -- To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/CAK00fOJmd9Z4gynS-F_bwxGt9hqk9+F5Z=gxjm7c9szen1q...@mail.gmail.com
