Bug#1000743: installation-reports: bootx64.efi didn't seem to get installed and no UEFI boot entry was created for Debian

[Pascal Hambourg]

Hello,

Le 28/11/2021 à 12:28, Adam Baxter a écrit :
>
> Comments/Problems:
> Once the installer had finished and prompted me to reboot, the system came back up in Dell's hardware check mode and
> some investigation revealed there was no UEFI boot entry for Debian.

Some UEFI firmwares are broken and do not handle EFI boot entries properly.

> /boot/efi
> └── EFI
> ├── debian
> │   ├── BOOTX64.CSV
> │   ├── fbx64.efi
> │   ├── grub.cfg
> │   ├── grubx64.efi
> │   ├── mmx64.efi
> │   └── shimx64.efi

At least GRUB itself was installed in the EFI partition.

> Shouldn't there normally be EFI/boot/bootx64.efi?

Not by default. It happens only if you choose to install a copy of the
boot loader in the removable device path. The option is available only
in expert install or after changing priority for questions to low.

> Additional issues:
> This laptop has an upgraded AX201 wifi card - the installer detected that I needed non-free firmware and I was able
> to load it from USB successfully. The message could be improved a bit with better instructions of where to
> get the firmware and what structure is needed on the external drive.

The installation manual provides all this information.

> I ended up grabbing https://saimei.ftp.acc.umu.se/cdimage/unofficial/non-free/firmware/testing/20211122/firmware.zip
> and extracting the firmware files from firmware-iwlwifi_20210818-1_all.deb
> Would the installer have coped if I'd just dropped that single deb file?

Yes, as stated in the installation manual.

> Maybe it'd be worth having an option to allow a user to tether a mobile phone via USB to grab the firmware online.

This is automatic if the phone emulates a USB-ethernet adapter.

> Also, a cdrom: entry was added to sources.list even though I installed from USB.

Because both contain the same ISO image so have the same data structure.

[Steve McIntyre]

On Sun, Nov 28, 2021 at 02:24:06PM +0100, Pascal Hambourg wrote:
>Hello,
>
>Le 28/11/2021 à 12:28, Adam Baxter a écrit :
>>
>> Comments/Problems:
>> Once the installer had finished and prompted me to reboot, the system came back up in Dell's hardware check mode and
>> some investigation revealed there was no UEFI boot entry for Debian.
>
>Some UEFI firmwares are broken and do not handle EFI boot entries properly.

I'm guessing this is similar to the firware bug we've seen before in
https://bugs.debian.org/905319 , in fact.

>> /boot/efi
>> └── EFI
>> ├── debian
>> │   ├── BOOTX64.CSV
>> │   ├── fbx64.efi
>> │   ├── grub.cfg
>> │   ├── grubx64.efi
>> │   ├── mmx64.efi
>> │   └── shimx64.efi
>
>At least GRUB itself was installed in the EFI partition.
>
>> Shouldn't there normally be EFI/boot/bootx64.efi?
>
>Not by default. It happens only if you choose to install a copy of the boot
>loader in the removable device path. The option is available only in expert
>install or after changing priority for questions to low.

Agreed. We deliberately do *not* install there by default as this can
cause other OSes not to boot. We try to be more accommodating than
Windows etc. :-/

Adam: if you boot the installer again in rescue mode, there is an
automated way to install to the removable media path, and that's
probably the easiest way to do this. The system will remember that you
need to do this in future and also install there on any further grub
package updates.

--
Steve McIntyre, Cambridge, UK. st...@einval.com
Welcome my son, welcome to the machine.

[Pascal Hambourg]

Le 28/11/2021 à 15:06, Steve McIntyre a écrit :
> On Sun, Nov 28, 2021 at 02:24:06PM +0100, Pascal Hambourg wrote:
>>
>>> Shouldn't there normally be EFI/boot/bootx64.efi?
>>
>> Not by default. It happens only if you choose to install a copy of the boot
>> loader in the removable device path. The option is available only in expert
>> install or after changing priority for questions to low.
>
> Agreed. We deliberately do *not* install there by default as this can
> cause other OSes not to boot. We try to be more accommodating than
> Windows etc. :-/

This is too detrimental to Debian IMO, there are too many broken UEFI
firmwares out there. As I suggested in a previous post, what about
setting grub2/force_efi_extra_removable true by default when the file
does not exist ?

[deb...@voltagex.org]

Hi
>>At least GRUB itself was installed in the EFI partition.
>>
>>> Shouldn't there normally be EFI/boot/bootx64.efi?
>>
>>Not by default. It happens only if you choose to install a copy of the boot
>>loader in the removable device path. The option is available only in expert
>>install or after changing priority for questions to low.
>
> Agreed. We deliberately do *not* install there by default as this can
> cause other OSes not to boot. We try to be more accommodating than
> Windows etc. :-/
>

Unless I did something wrong in the partitioning setup, there were no other operating systems. The only other EFI entry I had created in the firmware setup manually was one for the USB drive.

What do you mean by removable device in this case? /boot/EFI is on the same NVMe drive as the Debian install itself.

Thanks,
Adam

[Adam Baxter]

> The installation manual provides all this information.

OK, this is fair, I wasn't thinking about the manual as I've installed Debian quite a few times and know how the installation goes.

Perhaps the text could include a reminder to check the manual for more info on firmware loading, or even a QR code to take me to the correct place?

>> I ended up grabbing https://saimei.ftp.acc.umu.se/cdimage/unofficial/non-free/firmware/testing/20211122/firmware.zip
>> and extracting the firmware files from firmware-iwlwifi_20210818-1_all.deb
>> Would the installer have coped if I'd just dropped that single deb file?
>
> Yes, as stated in the installation manual.
>
>> Maybe it'd be worth having an option to allow a user to tether a mobile phone via USB to grab the firmware online.
>
> This is automatic if the phone emulates a USB-ethernet adapter.
>

Perhaps the prompt should say "We can download the firmware automatically if you are able to use an alternative connection, such as mobile tethering", although I wonder how this would work for non-free firmware.

>> Also, a cdrom: entry was added to sources.list even though I installed from USB.
>
> Because both contain the same ISO image so have the same data structure.

But Debian was looking for these files at /media/cdrom - would the installation USB be re-mounted at this location?

--Adam

[Steve McIntyre]

The *normal* way for UEFI boot is via vendor paths and boot
variables. The alternate path is primarily designed for removable
media, where you won't have boot variables set to point to the right
files. Hopefully the docs I've written in

https://wiki.debian.org/UEFI#Booting_a_UEFI_machine_normally

and

https://wiki.debian.org/UEFI#Booting_from_removable_media

might help explain some more.

--
Steve McIntyre, Cambridge, UK. st...@einval.com

We don't need no education.
We don't need no thought control.

[Pascal Hambourg]

Le 28/11/2021 à 23:07, Adam Baxter a écrit :
>>
>>> Maybe it'd be worth having an option to allow a user to tether a mobile phone via USB to grab the firmware online.
>>
>> This is automatic if the phone emulates a USB-ethernet adapter.
>>
> Perhaps the prompt should say "We can download the firmware automatically if you are able to use an alternative connection, such as mobile tethering", although I wonder how this would work for non-free firmware.

Sorry, there was a misunderstanding. I meant that a tethered phone can
be used as a network interface to download packages during the
installation, but not to download firmware for the installer itself.

>>> Also, a cdrom: entry was added to sources.list even though I installed from USB.
>>
>> Because both contain the same ISO image so have the same data structure.
> But Debian was looking for these files at /media/cdrom - would the installation USB be re-mounted at this location?

Not automatically (unless you create an appropriate udev rule or fstab
entry), but you can do it manually.