You are not logged in.
Hello. I recently ran sudo fwupdmgr get-updates and noticed there were some updates available. So next I ran sudo fwupdmgr update to install the available update.
Everything seeeems like it's going to work. But after the reboot, the update is still available. Seems like nothing happened.
I'm seeing this happen on my Dell XPS 13 and also my X1 Carbon.
$ sudo fwupdmgr get-updates
No upgrades for Thunderbolt Controller, current is 44.00: 44.00=same
XPS 13 9380
│
└─System Firmware:
│ Device ID: 6c24a747f97668873b761558e322398a91dbf394
│ Current version: 0.1.7.0
│ Minimum Version: 0.1.7.0
│ Vendor: Dell Inc.
│ Update State: success
│ GUID: ce945437-7358-49f1-95d8-6b694a10a755
│ Device Flags: • Internal device
│ • Updatable
│ • Requires AC power
│ • Supported on remote server
│ • Needs a reboot after installation
│ • Cryptographic hash verification is available
│ • Device is usable for the duration of the update
│
└─XPS 13 9380 System Update:
New version: 0.1.8.0
Remote ID: lvfs
Summary: Firmware for the Dell XPS 13 9380
License: Proprietary
Size: 22.4 MB
Vendor: Dell Inc.
Flags: is-upgrade
Description: Some new functionality has also been added:
• Supports new memory modules.
Here's the content of /boot, in case that's useful.
$ tree /boot
/boot
├── d96b874d6bf445e1a3c52c01a6f86be9
├── EFI
│ ├── arch
│ │ ├── fw
│ │ │ └── fwupd-ce945437-7358-49f1-95d8-6b694a10a755.cap
│ │ └── fwupdx64.efi
│ ├── BOOT
│ │ └── BOOTX64.EFI
│ ├── Linux
│ └── systemd
│ └── systemd-bootx64.efi
├── initramfs-linux-fallback.img
├── initramfs-linux.img
├── intel-ucode.img
├── loader
│ ├── entries
│ │ └── arch.conf
│ ├── loader.conf
│ └── random-seed
└── vmlinuz-linux
9 directories, 11 files
Here's bootctl status.
$ bootctl status
System:
Firmware: UEFI 2.70 (American Megatrends 5.13)
Secure Boot: disabled
Setup Mode: user
Current Boot Loader:
Product: systemd-boot 243.162-2-arch
Features: ✓ Boot counting
✓ Menu timeout control
✓ One-shot menu timeout control
✓ Default entry control
✓ One-shot entry control
✓ Support for XBOOTLDR partition
✓ Support for passing random seed to OS
ESP: /dev/disk/by-partuuid/95251c98-259c-442e-93bf-2db75813aeb1
File: └─/EFI/systemd/systemd-bootx64.efi
Random Seed:
Passed to OS: yes
System Token: set
Exists: yes
Available Boot Loaders on ESP:
ESP: /boot (/dev/disk/by-partuuid/95251c98-259c-442e-93bf-2db75813aeb1)
File: └─/EFI/systemd/systemd-bootx64.efi (systemd-boot 243.162-2-arch)
File: └─/EFI/BOOT/BOOTX64.EFI (systemd-boot 243.162-2-arch)
Boot Loaders Listed in EFI Variables:
Title: Linux Boot Manager
ID: 0x0002
Status: active, boot-order
Partition: /dev/disk/by-partuuid/95251c98-259c-442e-93bf-2db75813aeb1
File: └─/EFI/systemd/systemd-bootx64.efi
Title: Windows Boot Manager
ID: 0x0000
Status: inactive, boot-order
Partition: /dev/disk/by-partuuid/95251c98-259c-442e-93bf-2db75813aeb1
File: └─/EFI/Microsoft/Boot/bootmgfw.efi
Title: Linux Firmware Updater
ID: 0x0001
Status: active, boot-order
Partition: /dev/disk/by-partuuid/95251c98-259c-442e-93bf-2db75813aeb1
File: └─/EFI/arch/fwupdx64.efi
Boot Loader Entries:
$BOOT: /boot (/dev/disk/by-partuuid/95251c98-259c-442e-93bf-2db75813aeb1)
Default Boot Loader Entry:
title: arch
id: arch
source: /boot/loader/entries/arch.conf
linux: /vmlinuz-linux
initrd: /intel-ucode.img
/initramfs-linux.img
options: cryptdevice=UUID=7bacd8ad-b587-4cd4-b9cf-74c70a665650:cryptroot root=/dev/mapper/cryptroot rw ignore_loglevel debug
Any tips on debugging this?
Last edited by 1ptb3b (2019-11-23 23:18:21)
Offline
Did you carry out all of the required preliminary steps?
https://wiki.archlinux.org/index.php/Fw … OS_upgrade
Offline
Seems like I am in UEFI mode. I was also able to run efivars without any problem.
$ ls /sys/firmware/efi
config_table efivars esrt fw_platform_size fw_vendor runtime runtime-map systab
ESP is my first partition and is mounted under /boot.
$ sudo parted --list
Model: PC401 NVMe SK hynix 256GB (nvme)
Disk /dev/nvme0n1: 256GB
Sector size (logical/physical): 512B/512B
Partition Table: gpt
Disk Flags:
Numero Inicio Fin Tamaño Sistema de ficheros Nombre Banderas
1 1049kB 538MB 537MB fat32 ESP arranque, esp
2 538MB 256GB 256GB primary
$ df /boot
S.ficheros bloques de 1K Usados Disponibles Uso% Montado en
/dev/nvme0n1p1 523248 76400 446848 15% /boot
Offline
Offline
What's the next bit?
Offline
Offline
Yeah, I read the link you posted, but I'm confused because I think I covered all the points in the section you linked to.
I kept reading and it doesn't seem like the following sections apply to what I'm doing. Could you please be more explicit?
Offline
Offline
Ah, okay thanks. I do have to do that step? I already have the fwupd files in the EFI system partition.
$ ls /usr/lib/fwupd/efi
fwupdx64.efi
$ tree /boot
/boot
├── d96b874d6bf445e1a3c52c01a6f86be9
├── EFI
│ ├── arch
│ │ ├── fw
│ │ │ └── fwupd-ce945437-7358-49f1-95d8-6b694a10a755.cap
│ │ └── fwupdx64.efi
│ ├── BOOT
│ │ └── BOOTX64.EFI
│ ├── Linux
│ └── systemd
│ └── systemd-bootx64.efi
├── initramfs-linux-fallback.img
├── initramfs-linux.img
├── intel-ucode.img
├── loader
│ ├── entries
│ │ └── arch.conf
│ ├── loader.conf
│ └── random-seed
└── vmlinuz-linux
9 directories, 11 files
$ md5sum /usr/lib/fwupd/efi/fwupdx64.efi /boot/EFI/arch/fwupdx64.efi
fd42bae4d6d54100d7a9a84f9318cdcb /usr/lib/fwupd/efi/fwupdx64.efi
fd42bae4d6d54100d7a9a84f9318cdcb /boot/EFI/arch/fwupdx64.efi
But, maybe the path is wrong. I noticed the wiki says esp/efi, with a lowercase efi, but my filesystem has EFI. I wonder if that makes a difference.
Last edited by 1ptb3b (2019-11-23 22:14:48)
Offline
Offline
Hm. Interesting. This seems to have fixed it.
# Delete Windows boot entry.
# efibootmgr --bootnum 0000 --delete-bootnum
# Fix hole left by Windows entry.
# efibootmgr --bootorder 0002,0001
# efibootmgr --bootnext 0001
$ efibootmgr
BootCurrent: 0002
Timeout: 2 seconds
BootOrder: 0002,0001
Boot0001* Linux Firmware Updater
Boot0002* Linux Boot Manager
$ reboot
Although, the --verbose output is a little weird...
$ efibootmgr --verbose
BootCurrent: 0002
Timeout: 2 seconds
BootOrder: 0002,0001
Boot0001* Linux Firmware UpdaterCould not parse device path: Invalid argument
That error is weird, but nothing seems broken. Also, originally, that error was on the Windows boot entry, which is why I thought of deleting it in the first place. (I only run Linux, no Windows.)
But now, all the updates are installed! Woo!
Last edited by 1ptb3b (2019-11-25 16:43:07)
Offline
Have you actually copied fwupdx64.efi to the correct location yet?
Offline
No, I didn't need to copy anything manually.
According to the article you posted, https://wiki.archlinux.org/index.php/Fw … upd_to_ESP, it seems like fwupd is copying the efi files to the right place.
This seems to match my experience because the file fwupdx64.efi has been in my EFI system partition since the start.
$ tree /boot
/boot
├── d96b874d6bf445e1a3c52c01a6f86be9
├── EFI
│ ├── arch
│ │ ├── fw
│ │ │ └── fwupd-ce945437-7358-49f1-95d8-6b694a10a755.cap
│ │ └── fwupdx64.efi
│ ├── BOOT
│ │ └── BOOTX64.EFI
│ ├── Linux
│ └── systemd
│ └── systemd-bootx64.efi
├── initramfs-linux-fallback.img
├── initramfs-linux.img
├── intel-ucode.img
├── loader
│ ├── entries
│ │ └── arch.conf
│ ├── loader.conf
│ └── random-seed
└── vmlinuz-linux
9 directories, 11 files
Offline
What I've been trying to point you to all this time is that the wiki tells you to copy the files to EFI/fwupdx64.efi whereas you have it copied to EFI/arch/fwupdx64.efi.
They are not the same location.
Offline
Ah, yes. It seems like the Wiki is wrong. The files do not have to be at EFI/fwupdx64.efi in order for the upgrades to work.
fwupdmgr has installed them at EFI/arch/fwupdx64.efi and the update worked after tweaking my boot entries. I'm 100% up to date now. No more updates left to install. I saw them get installed on the Dell boot screen. fwupdmgr doesn't report any pending updates.
Are you thinking this is just a coincidence? Or the wrong way to "fix" this issue?
Offline
I think it's a coincidence or maybe related to the boot loader you're using. EFISTUB for instance would normally be at the $esp root and doesn't even have/use any sub-directories at all unless you've manually configured your system differently (e.g. /boot != $esp, you used bind mounts or something, etc...).
$esp/EFI/arch is a non-standard EFI directory, afaik, it makes no sense for that to be the location it uses unless you've configured that as the $esp/EFI root for fwupd yourself somehow.
EDIT: I just checked 2 systems, one that has used systemd-boot and is on EFISTUB nowadays and one that has only ever used EFISTUB. The one that had used systemd-boot at some point does also have an EFI/arch/... copy. The EFISTUB has none and errors out unless manually copied to $esp/EFI.
EDIT2: For the heck of it I completely cleared out the system that was systemd-boot in the past and EFISTUB now. If I don't create and copy over fwupdx64.efi to /boot/EFI (/boot == $esp in my case), it will error out. Just creating the EFI directory is not enough.
Once created and copied over, fwupd itself created the 'arch' and 'arch/fw' subdirectories, also placing itself in the first and the bios updates in the latter. If there are no bios updates, the 'arch' and 'arch/fw' directory are not created.
EDIT3: It seems creating the directory is indeed enough nowadays with the following 2 notes; 1) the directory MUST be upper-cased and 2) the fwupd service must be restarted after creating the directory.
I'll update the WIKI.
EDIT4: Wiki edit done
Last edited by Omar007 (2019-11-25 13:15:50)
Offline
Just gave the same treatment of deleting the Windows boot entry and reordering the boot entries to my X1 Carbon, which had the same problem of not installing updates.
# efibootmgr --bootnum 0000 --delete-bootnum
# efibootmgr --bootorder 0002,0001
# efibootmgr --bootnext 0001
It also "fixed" the issue. My X1 Carbon is now fully up to date.
I believe I'm using systemd-boot for both of these machines. I ran `bootctl install` during initial installation.
Offline
I had the same issue (fwupdmgr install update, reboot and nothing happens). I am booting using EFISTUB and always have. I have a Thinkpad X1 Carbon 7th gen.
For me too, the solution had to do with the booting order. I changed the booting order from bios to make sure the Firmware Update EFI app was the first in the booting order and the update completed successfully.
Offline
I had the same issue, Thinkpad X1 Carbon 7th Gen. The above didn't quite fix it but gave me the clue needed to fix it.
BIOS Startup "Boot Order Lock" blocks fwupdmgr's flow. It stomps on BootNext, so the system never boots into the step to apply the updates.
The clue was when I used
efibootmgr --bootorder .....
and on the next reboot it was fully restored, including the deleted bootnum reappearing.
Lightbulb moment. Checked BIOS, found the Boot Order Lock, disabled it, continued ... updates not applied but order had probably already been stomped on. Try one final time and ... success!
Offline