Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > linux.debian.user > #178849 > unrolled thread

Broken Dell UEFI Firmware?

Back to article view | Back to linux.debian.user

Contents

  Broken Dell UEFI Firmware? Kent West <westk@acu.edu> - 2017-03-14 22:50 +0100
    Re: Broken Dell UEFI Firmware? Steve McIntyre <steve@einval.com> - 2017-03-16 16:20 +0100
      Re: Broken Dell UEFI Firmware? Kent West <westk@acu.edu> - 2017-03-16 21:30 +0100

#178849 — Broken Dell UEFI Firmware?

[Multipart message — attachments visible in raw view] — view raw

I have a new Dell Precision 3620.

I have just installed Jessie on the drive, in UEFI mode, creating a
separate EFI partition, FAT-formatted, in a GPT partition table.

After install, the "grubx64.efi" file is in in the "\[GUID]\EFI\debian"
directory.

But when I boot the machine, it fails to boot, not being able to find a
bootable device.

When I go into the UEFI, I can manually specify a boot option to point to
this directory, but when I reboot, it still fails. When I go back into the
UEFI, and look at the boot option I specified, I see that the UEFI silently
changed my specific "\[GUID\EFI\debian\grubx64.efi" entry to
"\]GUID\BOOT\BOOTX64.efi".

There seems to be no way to over-ride this silent bait-and-switch.

I can boot from a rescue drive and create the "\BOOT" directory and copy
the "grubx64.efi" file into it with the "BOOTX64.efi" name, and Debian
boots fine, but I shouldn't have to do that, methinks.

I downloaded/installed the most recent "BIOS" from the Dell site, to none
effect.

So, my question:

Is Dell's UEFI implementation broken, or am I simply overlooking something?
I'm going to go see if I can make the setting stick if I use
Debian's efibootmgr utility.

Thanks!

-- 
Kent West                    <")))><
Westing Peacefully - http://kentwest.blogspot.com

[toc] | [next] | [standalone]

#178927

[ Note Reply-To set ]

Kent West wrote:
>
>I have a new Dell Precision 3620.
>
>I have just installed Jessie on the drive, in UEFI mode, creating a
>separate EFI partition, FAT-formatted, in a GPT partition table.
>
>After install, the "grubx64.efi" file is in in the "\[GUID]\EFI\debian"
>directory.

I'm unclear - is this what the installer set up during the
installation? There shouldn't be any GUIDs visible in the
filesystem...

>But when I boot the machine, it fails to boot, not being able to find a
>bootable device.
>
>When I go into the UEFI, I can manually specify a boot option to point to
>this directory, but when I reboot, it still fails. When I go back into the
>UEFI, and look at the boot option I specified, I see that the UEFI silently
>changed my specific "\[GUID\EFI\debian\grubx64.efi" entry to
>"\]GUID\BOOT\BOOTX64.efi".
>
>There seems to be no way to over-ride this silent bait-and-switch.

I've never seen a UEFI implementation where you can control access
like that way, to be honest. It looks like what you're seeing is the
standard way of describing the removable media path.

>I can boot from a rescue drive and create the "\BOOT" directory and copy
>the "grubx64.efi" file into it with the "BOOTX64.efi" name, and Debian
>boots fine, but I shouldn't have to do that, methinks.
>
>I downloaded/installed the most recent "BIOS" from the Dell site, to none
>effect.
>
>So, my question:
>
>Is Dell's UEFI implementation broken, or am I simply overlooking something?
>I'm going to go see if I can make the setting stick if I use
>Debian's efibootmgr utility.

Well, efibootmgr is how you'd normally manage the EFI boot
variables. Have you been trying to do this by hand for some reason?

-- 
Steve McIntyre, Cambridge, UK.                                steve@einval.com
< liw> everything I know about UK hotels I learned from "Fawlty Towers"

[toc] | [prev] | [next] | [standalone]

#178936

[Multipart message — attachments visible in raw view] — view raw

On Thu, Mar 16, 2017 at 10:10 AM, Steve McIntyre <steve@einval.com> wrote:

> [ Note Reply-To set ]
>
> Kent West wrote:
> >
> >I have a new Dell Precision 3620.
> >
> >I have just installed Jessie on the drive, in UEFI mode, creating a
> >separate EFI partition, FAT-formatted, in a GPT partition table.
> >
> >After install, the "grubx64.efi" file is in in the "\[GUID]\EFI\debian"
> >directory.
>
> I'm unclear - is this what the installer set up during the
> installation? There shouldn't be any GUIDs visible in the
> filesystem...
>
>
Sorry; I wasn't clear. Perhaps "[GUID]" is the wrong terminology. I was
using it as shorthand for:

ACPI(a0341d0,0)PCI(17,0)SATA(0,ffff,0)HD(1,800,ee000,39350c63-e96c-47f1-ba2f-6d5b8113b3a4)File(\EFI\debian\grubx64.efi)

which is the way it's reported by efibootmgr.


>But when I boot the machine, it fails to boot, not being able to find a
> >bootable device.
> >
> >When I go into the UEFI, I can manually specify a boot option to point to
> >this directory, but when I reboot, it still fails. When I go back into the
> >UEFI, and look at the boot option I specified, I see that the UEFI
> silently
> >changed my specific "\[GUID\EFI\debian\grubx64.efi" entry to
> >"\]GUID\BOOT\BOOTX64.efi".
> >
> >There seems to be no way to over-ride this silent bait-and-switch.
>
> I've never seen a UEFI implementation where you can control access
> like that way, to be honest. It looks like what you're seeing is the
> standard way of describing the removable media path.
>

Probably a large part of my problem is that I'm new to UEFI stuff. I spent
all weekend trying to learn the basics on a VirtualBox machine (very
minimal Jessie install), and VirtualBox had a fairly nice UEFI firmware
interface; a little confusing, but once I understood how all the options
worked, pretty decent.

The VirtualBox UEFI firmware interface allowed me to specify different
media boot files; I could specify this grubx64.efi in that directory, and
name it "Jessie 64-bit", and I could specify another boot option, perhaps
named "Jessie 32-bit", that pointed to grubx32.efi in a different directory
(this last option I didn't actually do, but I'm confident I could have).

When I got to my physical hardware Dell, I expected to see a similar UEFI
firmware interface (accessed by F12 after Dell splashscreen on power-up),
and sure enough, there was such an interface. But it looked a lot different
(being Dellish (that rhymes with "hellish")), just like one manufacturer's
BIOS looks different from that of another manufacturer, but tends to do
pretty much the same stuff.


> >I can boot from a rescue drive and create the "\BOOT" directory and copy
> >the "grubx64.efi" file into it with the "BOOTX64.efi" name, and Debian
> >boots fine, but I shouldn't have to do that, methinks.
>

I have since learned that "\BOOT\BOOT64.efi" seems to be the lowest-common
denominator file-name, and is the fall-back path when all other paths fail.

So perhaps I'm specifying something incorrectly. But I don't think so,
leading me to believe Dell's interface is broken.

>
> >I downloaded/installed the most recent "BIOS" from the Dell site, to none
> >effect.
> >
> >So, my question:
> >
> >Is Dell's UEFI implementation broken, or am I simply overlooking
> something?
> >I'm going to go see if I can make the setting stick if I use
> >Debian's efibootmgr utility.
>

I have since read that some UEFI firmware is poorly written (e.g.,
https://www.happyassassin.net/2014/01/25/uefi-boot-how-does-that-actually-work-then/
writes, among other things, "Yes, the UEFI forum should’ve realized that
firmware engineers couldn’t code their way out of a goddamned paper bag and
just ordered them to do so, but still, it’s ultimately the firmware
engineers who should be lined up against the nearest wall. Wait, we can
simplify that. “Any firmware is crap code”. Usually pretty accurate.").

>
> Well, efibootmgr is how you'd normally manage the EFI boot
> variables. Have you been trying to do this by hand for some reason?
>

I tried to do it via the Dell UEFI interface (what Dell still calls the
"BIOS Setup" - F12 at power-on). When that didn't work, I started tinkering
with efibootmgr, but it hasn't helped, because, I have come to conclude,
Dell's firmware engineers write "crap code".

Unless I'm the one actually doing something wrong. In which case I'll feel
stupid. (Which I do a lot of anyway, so, meh.)


>
> --
> Steve McIntyre, Cambridge, UK.
> steve@einval.com
> < liw> everything I know about UK hotels I learned from "Fawlty Towers"
>

"Fawlty Towers" - fun times.

-- 
Kent West                    <")))><
Westing Peacefully - http://kentwest.blogspot.com

[toc] | [prev] | [standalone]

Back to top | Article view | linux.debian.user

csiph-web