fwupd not detecting my UEFI partition, partitioning issue?

asgoredreemurr0203 · 2024-11-15 10:47:16

Hello,
I did a fresh install of Arch yesterday on a Thinkpad T480. Everything runs fine except fwupdmgr can’t find my uefi partition (which is mounted as /boot/efi). I've tried hardcoding its way to /etc/fwupd/uefi.conf, but it still can’t find it. I've also made sure udisks2 is installed. I've ran a few other tests trying to troubleshoot, here are their results. (i've added some description to those images, hoping it'll make it easier to read)

If i'm correct and actually messed up during my partitioning, can i use my usb live environment to chroot into my system, format the efi partition and recreate it properly? Instead of reinstalling the whole system and lose my configurations?

PS: fwupd isn’t that important i think, since that model is kind of old and the only update showing up is some Secure boot update which i don’t care much about (thunderbolt was already updated to 23.00 via Windows).
I've made this post essentially to learn more, and in case this EFI partition issue could become a problem in the future (better fix it now than later huh).

Thanks for reading.

cryptearth · 2024-11-15 11:56:24

please post console output as text instead of images

why do you think fwupdmgr should find a partition?
fwupdmgr is used to update firmware of a device - so if at all it would detect the drive

asgoredreemurr0203 · 2024-11-15 12:13:22

Sorry, i'll upload them when i'm back home.
What i *understood* is that fwupdmgr wants to update files related to EFI, but it can’t find any. I think it is because my EFI partition is not correctly "labeled" (not sure if it is a correct term).
The error message i get when using fwupdmgr is "ESP UEFI partition not detected or configured". (damn me, i thought i wrote it in my post, so sorry).
It indeed detects devices with fwupdmgr get-devices (and even tells me that one update is available), but some of them show the error message alongside their infos. And the update is, therefore, not working. I'll also share this result as soon as i can

Last edited by asgoredreemurr0203 (2024-11-15 12:19:25)

cryptearth · 2024-11-15 12:18:42

please post the full output of fwupdmgr including the commands

Head_on_a_Stick · 2024-11-15 13:00:48

asgoredreemurr0203 wrote:

here are their results.

I think you are correct, the ESP seems to be of the wrong type.

This should fix things:

# parted /dev/nvme0n1 set 1 esp on

I'm in Windows atm though so that might not be right, wait for somebody to correct me or use gparted instead.

asgoredreemurr0203 · 2024-11-15 15:31:35

Head_on_a_Stick wrote:

asgoredreemurr0203 wrote:
here are their results.
I think you are correct, the ESP seems to be of the wrong type.
This should fix things:
# parted /dev/nvme0n1 set 1 esp on
I'm in Windows atm though so that might not be right, wait for somebody to correct me or use gparted instead.

Adding the esp flag to /boot/efi using gparted fixed this error! Thanks a lot!!
Some updates still can't install but it is unrelated...

Devices that were not updated correctly:
 • System Firmware (0.1.42 → 0.1.52)
 • UEFI dbx (220 → 371)
Devices that have been updated successfully:
 • Intel Management Engine (184.80.3746 → 184.96.4657)

UEFI dbx:
  │   Identifiant de l'appareil: 362301da643102b9f38477387e2193e57abaa590
  │   Version précédente: 220
  │   Durée d'installation: 1 seconde
  │   État de mise à jour: Échec      # Update state: Failure
  │   Erreur de mise à jour: failed to write-firmware: Blocked executable in the ESP, ensure grub and shim are up to date: could not find EFI DP      # Update error message
  │   Dernière modification: 2024-11-15
  │   GUID:               5971a208-da00-5fce-b5f5-1234342f9cf7
  │   Drapeaux de périphérique: • Périphérique interne
  │                       • Mise à jour possible
  │                       • Supported on remote server
  │                       • Doit redémarrer après une mise à jour
  │                       • Le périphérique est utilisable pendant la durée de la mise à jour
  │                       • Seules les mises à jour de version sont autorisées
  │                       • Signed Payload
  │ 
  └─Secure Boot dbx Configuration Update:
        Nouvelle version: 371
        Remote ID:        lvfs
        Release ID:       35287
        Résumé:           UEFI Secure Boot Forbidden Signature Database
        Variante:         x64
        Licence:          Propriétaire
        Taille:           21,2 Ko
        Created:          2023-05-09
        Urgence:          Haute
          Tested:         2024-06-06
          Distribution:   ubuntu 22.04
          Old version:    267
          Version[fwupd]: 1.9.15
          Tested:         2024-06-04
          Distribution:   fedora 39 (workstation)
          Old version:    77
          Version[fwupd]: 1.9.20
          Tested:         2024-04-24
          Distribution:   ubuntu 22.04
          Old version:    83
          Version[fwupd]: 1.9.16
          Tested:         2024-03-21
          Distribution:   fedora 39 (workstation)
          Old version:    217
          Version[fwupd]: 1.9.15
          Tested:         2024-02-20
          Distribution:   fedora 39 (workstation)
          Old version:    77
          Version[fwupd]: 1.9.5
          Tested:         2024-01-12
          Distribution:   fedora 39 (workstation)
          Old version:    220
          Version[fwupd]: 1.9.11
          Tested:         2023-07-11
          Distribution:   fedora 38 (workstation)
          Old version:    211
          Version[fwupd]: 1.9.2
          Tested:         2023-07-03
          Distribution:   ubuntu 22.04
          Old version:    220
          Version[fwupd]: 1.9.3
        Fournisseur:      Linux Foundation
        Release Flags:    • Trusted payload
                          • Trusted metadata
        Description:      
        Insecure versions of the Microsoft Windows boot manager affected by Black Lotus were added to the list of forbidden signatures due to a discovered security problem.This updates the dbx to the latest release from Microsoft.
        
        Before installing the update, fwupd will check for any affected executables in the ESP and will refuse to update if it finds any boot binaries signed with any of the forbidden signatures.Applying this update may also cause some Windows install media to not start correctly.
        Issue:            CVE-2022-21894
        Somme de contrôle: fc3feb015df2710fcfa07583d31b5975ee398357016699cfff067f422ab91e13

This on apparently concerns Windows, which doesn't matter since i'm not dual booting, but getting the update prompt is kinda annoying

System Firmware:
│ │   Identifiant de l'appareil: f2a0ebaf16bf5280a057b882965430a4770b70cf
│ │   Version précédente: 0.1.42
│ │   État de mise à jour: Échec     # Update state: Failure
│ │   Erreur de mise à jour: failed to run update on reboot: expected 0.1.52 and got 0.1.42     # Update error message
│ │   Dernière modification: 2024-11-15
│ │   GUID:               dc7f0308-1ef8-4774-9ba5-89a58c4d731c
│ │   Drapeaux de périphérique: • Périphérique interne
│ │                       • Mise à jour possible
│ │                       • Le système nécessite une source d'alimentation externe
│ │                       • Supported on remote server
│ │                       • Doit redémarrer après une mise à jour
│ │                       • Cryptographic hash verification is available
│ │                       • Le périphérique est utilisable pendant la durée de la mise à jour
│ │ 
│ └─ThinkPad T480 System Update:
│       Nouvelle version: 0.1.52
│       Remote ID:        lvfs
│       Release ID:       96444
│       Résumé:           Lenovo ThinkPad T480 System Firmware
│       Licence:          Propriétaire
│       Taille:           9,5 Mo
│       Created:          2024-07-30
│       Urgence:          Haute
│       Fournisseur:      Lenovo
│       Release Flags:    • Trusted payload
│                         • Trusted metadata
│       Description:      
│       Lenovo ThinkPad T480 System Firmware
│       
│       • Updated MCU to m_c0_806ea_000000f6, Kabylake-U MCU to m_c0_806e9_000000f6.
│       • Version 04.35.000 code of FIT's InROM diagnostics.
│       Somme de contrôle: 00518529b38a06ae5bf077325ff5108242d86d5653250063d215d4b8ffc8740b

Sorry for those being in french, no clue how can i change the language only for those message . (I've aded comments to the error lines)

EDIT1: After trying another time, the BIOS update is installing right now. Hope it won’t break anything lol.
EDIT2: It does work! I'll look for a way to install that dbx update now

Last edited by asgoredreemurr0203 (2024-11-15 16:11:14)

cryptearth · 2024-11-15 16:20:52

for code which implements i18n you can use

LC_ALL=C <command>

to get native output (should work for most GNU tools)

tionichm · 2024-12-25 20:29:35

Head_on_a_Stick wrote:

asgoredreemurr0203 wrote:
here are their results.
I think you are correct, the ESP seems to be of the wrong type.
This should fix things:
# parted /dev/nvme0n1 set 1 esp on
I'm in Windows atm though so that might not be right, wait for somebody to correct me or use gparted instead.

I was also experiencing this issue. I partitioned my disk with fdisk, and I am pretty sure that I used the correct partition type. Could it be that the efi flag needs to be added to the efi partition in order for fwupd to detect the partition? See section 2.1 in https://wiki.archlinux.org/title/EFI_system_partition

Head_on_a_Stick · 2024-12-25 20:36:54

Well for my laptop the firmware will read any FAT partition for EFI loaders regardless of partition type.

I was booting using the gummiboot EFI stub loader, which was fine with an incorrect ESP type (I had removed the partition code with parted and forgot to replace it), but when I switched to the systemd-boot version it refused to start unless the ESP had the correct "flag" (partition type).

cryptearth · 2024-12-26 00:38:58

@Stick
as we've seen so many issues about boot issues often turn out to be user error - maybe that's something to be added into the list of question to be asked: what's the gpt guid of the esp?
often we say "it's a bad implementation of the systems firmware" when a uefi doesn't want to save a new boot entry properly but the user has to use the fallback path - but according to the uefi specs it demands the correct gpt uuid - so what about not all those uefi implementations were faulty but just followed the spec very strictly and its the users not correctly set the gpt uuid to C12A7328-F81F-11D2-BA4B-00A0C93EC93B
I don't recall this was asked in any of the many topics about boot issues
so what about the actual "fault" of a given systems firmware implemenation is to be not strict enough and hence just takes any FAT partition no matter its gpt uuid?
I, too, often wrote: "many firmware are just designed and tested with windows" - well, yea, because the windows installer which creates the ESP on a clean drive does its job properly and sets the correct type and flags - where as with the very manual way of how arch is to be installed there're a lot of opportunities a user may screw up and either set the wrong type or non at all and hence the ESP ends up to look as something different to the uefi - which then in turn results in boot entries not saved or deleted on reboot?
I figured a few commands for fdisk/gdisk and blkid/lsblk - but it all comes back with quite a lot of verbose information - someone may know a smarter command to get the gpt guid partition type?

Head_on_a_Stick · 2024-12-26 11:56:09

cryptearth wrote:

maybe that's something to be added into the list of question to be asked: what's the gpt guid of the esp?

That question is already on my list :-)

cryptearth wrote:

I don't recall this was asked in any of the many topics about boot issues

I usually ask for the output of `parted -l`, which show the "flags" and so will identify an incorrect partition code for the ESP.

EDIT:

sgdisk -i Y /dev/sdX | awk '/Partition GUID/{print $4}'

EDIT2: this covers most information:

lsblk -o name,uuid,partuuid,parttype,mountpoint

The filesystem UUIDs for the bootloader, the partition UUID for the NVRAM boot entries, and the partition GUID for fussy buggers like systemd-boot.

Last edited by Head_on_a_Stick (2024-12-26 12:41:40)

Arch Linux

#1 2024-11-15 10:47:16

fwupd not detecting my UEFI partition, partitioning issue?

#2 2024-11-15 11:56:24

Re: fwupd not detecting my UEFI partition, partitioning issue?

#3 2024-11-15 12:13:22

Re: fwupd not detecting my UEFI partition, partitioning issue?

#4 2024-11-15 12:18:42

Re: fwupd not detecting my UEFI partition, partitioning issue?

#5 2024-11-15 13:00:48

Re: fwupd not detecting my UEFI partition, partitioning issue?

#6 2024-11-15 15:31:35

Re: fwupd not detecting my UEFI partition, partitioning issue?

#7 2024-11-15 16:20:52

Re: fwupd not detecting my UEFI partition, partitioning issue?

#8 2024-12-25 20:29:35

Re: fwupd not detecting my UEFI partition, partitioning issue?

#9 2024-12-25 20:36:54

Re: fwupd not detecting my UEFI partition, partitioning issue?

#10 2024-12-26 00:38:58

Re: fwupd not detecting my UEFI partition, partitioning issue?

#11 2024-12-26 11:56:09

Re: fwupd not detecting my UEFI partition, partitioning issue?

Board footer