Re: UEFI works with USB but not with HDD
On Fri, Jun 26, 2015 at 06:16:13PM +0200, Dan wrote:
>On Fri, Jun 26, 2015 at 4:29 PM, Steve McIntyre <steve@einval.com> wrote:
>> Dan wrote:
>>
>>>I just bought a desktop (Dell T5810). I tried to install Jessie with
>>>UEFI. The USB installation (netinst) works perfectly. I installed the
>>>whole system and I can see it in the UEFI/BIOS menu. Surprisingly when
>>>I try to boot the system I get "No bootable devices found"
>>>
>>>I tried all the options of the BIOS but it does not work. I already
>>>installed Debian with UEFI in another system and it worked fine. Would
>>>that mean that I have a buggy BIOS? What surprises me the most is that
>>>the USB/UEFI works but not the HDD/UEFI.
>>
>> Unfortunately, it's not that uncommon. Lots of UEFI implementations
>> are really bad so far - testing seems to be essentially "does it work
>> with Windows?" and nothing more.
>>
>> As already suggested, try running "efibootmgr -v" on the system and
>> see what it says. If needs be, use the installer in Rescue mode to get
>> there. With Jessie, I also added an option in Rescue mode to add a
>> "removable media" boot entry on your hard disk so that even really
>> brain-dead UEFI setups should still boot...
>>
>
>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!
--
Steve McIntyre, Cambridge, UK. steve@einval.com
Who needs computer imagery when you've got Brian Blessed?
Reply to: