[SOLVED] Error updating firmware: "Error splicing file"

iavr · 2024-04-24 03:55:00

I'm running "fwupdmgr update" but it's failing with the following error:

Failed to copy /usr/lib/fwupd/efi/fwupdx64.efi to /boot/EFI/arch/fwupdx64.efi: Error splicing file: Operation not permitted

Edit: the error message appears immediately after downloading the update. The file /boot/EFI/arch/fwupdx64.efi does get created, but it is 0 bytes. There is plenty of available space on the /boot partition.

Software versions:

local/linux 6.8.7.arch1-1
    The Linux kernel and modules
local/fwupd 1.9.18-1
    Simple daemon to allow session software to update firmware
local/fwupd-efi 1.6-1
    EFI Application used by uefi-capsule plugin in fwupd

Info about the firmware in question:

LENOVO 21FACTO1WW
│
├─System Firmware:
│ │   Device ID:          e6d3b0871e8e4a4a79aa608e778219790bd93efb
│ │   Summary:            UEFI System Resource Table device (updated via NVRAM)
│ │   Current version:    0.1.3
│ │   Vendor:             Lenovo (DMI:LENOVO)
│ │   Update State:       Failed
│ │   Update Error:       Failed to copy /usr/lib/fwupd/efi/fwupdx64.efi to /boot/EFI/arch/fwupdx64.efi: Error splicing file: Operation not permitted
│ │   Last modified:      2024-04-24 03:31
│ │   GUID:               e286e826-12ed-41fd-9417-2f47d31f4bcb
│ │   Device Flags:       • Internal device
│ │                       • Updatable
│ │                       • System requires external power source
│ │                       • Supported on remote server
│ │                       • Needs a reboot after installation
│ │                       • Cryptographic hash verification is available
│ │                       • Device is usable for the duration of the update
│ │   Device Requests:    • Message
│ │ 
│ └─ThinkPad P16 Gen 2 System Update:
│       New version:      0.1.51
│       Remote ID:        lvfs
│       Release ID:       86592
│       Summary:          Lenovo ThinkPad P16 Gen 2 System Firmware
│       License:          Proprietary
│       Size:             28.8 MB
│       Created:          2024-03-04
│       Urgency:          High
│       Tested by Lenovo:
│         Tested:         2024-03-04
│         Distribution:   ubuntu 22.04
│         Old version:    0.1.18
│         Version[fwupd]: 1.7.9
│       Vendor:           Lenovo
│       Release Flags:    • Trusted metadata
│                         • Is upgrade
│                         • Tested by trusted vendor
│       Description:      
│       Lenovo Lenovo ThinkPad P16 Gen 2 System Firmware Version 1.51Updated Realtek Driver.Updated the microcode.Update Diagnostics module to version 04.32.Fixed an issue where Dock Mac address isn't cloned to system when enable MAC Pass through.Fixed an issue where Fnlock was switched in Quick Clean Mode.
│       Checksum:         51eac91201dc7242aa3e597f44ceb0b72b6ce7cfade2d0069331bb7807d4ae55

Googling the error message turns up nothing, and the Arch docs on fwupd are fairly lean, so I'm not sure where to begin. Anyone have any suggestions, please?

Last edited by iavr (2024-04-25 18:50:28)

gkralik · 2024-04-24 06:48:57

Same here. Downgrading fwupd to 1.9.16-1 seems to solve the issue.

seth · 2024-04-24 07:24:48

There is plenty of available space on the /boot partition.

what is "plenty" and is that actually the relevant filesystem?

du /usr/lib/fwupd/efi/fwupdx64.efi
df
df -i
lsblk -f

F5,… sems to be an upstream bug then, pot. actual permission error.

Edit more: https://github.com/fwupd/fwupd/issues/7144
Possibly https://github.com/fwupd/fwupd/commit/c … 237f498969

Last edited by seth (2024-04-24 07:29:49)

gkralik · 2024-04-24 07:29:11

I can confirm that the firmware update was successful after downgrading fwupd to 1.9.16-1. fwupd-efi is at version 1.6-1.

For me, plenty of free space means 94MB free on the FAT32 EFI partition. It is not an issue with free space - fwupdx64.efi is 66KB.

gkralik · 2024-04-24 07:47:18

I have opened a bug upstream (https://github.com/fwupd/fwupd/issues/7166). This looks like it could be related to the SystemCallFilter changes in v1.9.17.

Edit: just saw your post, @seth. It does look similar to #7144.

Last edited by gkralik (2024-04-24 07:48:11)

gkralik · 2024-04-24 08:30:43

@iavr Can you try adding `splice` to the `SystemCallFilter` list in /usr/lib/systemd/system/fwupd.service and see if that helps?

Edit: to be more specific, in /usr/lib/systemd/system/fwupd.service replace this:

SystemCallFilter=@basic-io @file-system @io-event @ipc @network-io @process @sync ioctl uname @raw-io

with this:

SystemCallFilter=@basic-io @file-system @io-event @ipc @network-io @process @sync ioctl uname @raw-io splice

Then restart the service with sudo systemctl restart fwupd.service and try the update again.

Last edited by gkralik (2024-04-24 08:34:22)

gkralik · 2024-04-24 12:56:33

Upstream just merged a possible fix: https://github.com/fwupd/fwupd/pull/7171

iavr · 2024-04-24 22:13:10

seth wrote:

du /usr/lib/fwupd/efi/fwupdx64.efi
df
df -i
lsblk -f

18:06:52 ~$ du /usr/lib/fwupd/efi/fwupdx64.efi 
68      /usr/lib/fwupd/efi/fwupdx64.efi
18:07:12 ~$ df
Filesystem      1K-blocks      Used  Available Use% Mounted on
dev              65763808         0   65763808   0% /dev
run              65779204      2048   65777156   1% /run
efivarfs              196        71        121  38% /sys/firmware/efi/efivars
/dev/nvme1n1p2 3934783380 501048484 3233784084  14% /
tmpfs            65779204      8432   65770772   1% /dev/shm
/dev/nvme1n1p1    2093048    226464    1866584  11% /boot
/dev/nvme0n1p1 3936847636 461328456 3275463512  13% /var
tmpfs            65779208    147412   65631796   1% /tmp
tmpfs            13155840     12120   13143720   1% /run/user/1000
18:07:26 ~$ df -i
Filesystem        Inodes   IUsed     IFree IUse% Mounted on
dev             16440952     770  16440182    1% /dev
run             16444801    1314  16443487    1% /run
efivarfs               0       0         0     - /sys/firmware/efi/efivars
/dev/nvme1n1p2 249921536 2097139 247824397    1% /
tmpfs           16444801      20  16444781    1% /dev/shm
/dev/nvme1n1p1         0       0         0     - /boot
/dev/nvme0n1p1 250052608   36549 250016059    1% /var
tmpfs            1048576      63   1048513    1% /tmp
tmpfs            3288960      97   3288863    1% /run/user/1000
18:07:28 ~$ lsblk 
NAME        MAJ:MIN RM  SIZE RO TYPE MOUNTPOINTS
nvme1n1     259:0    0  3.7T  0 disk 
├─nvme1n1p1 259:1    0    2G  0 part /boot
└─nvme1n1p2 259:2    0  3.7T  0 part /
nvme0n1     259:3    0  3.7T  0 disk 
└─nvme0n1p1 259:4    0  3.7T  0 part /var

gkralik wrote:

@iavr Can you try adding `splice` to the `SystemCallFilter` list in /usr/lib/systemd/system/fwupd.service and see if that helps?

Added "splice" to /usr/lib/systemd/system/fwupd.service as described in your post; sudo systemctl daemon-reload; sudo systemctl restart fwupd.service

"fwupdmgr update" still gives exactly the same error message.

seth · 2024-04-24 22:22:47

https://github.com/fwupd/fwupd/pull/717 … 34b67e8dcd added a bunch of more filters - try those before considering a downgrade (to test the patch)

iavr · 2024-04-25 00:04:44

seth wrote:

https://github.com/fwupd/fwupd/pull/717 … 34b67e8dcd added a bunch of more filters - try those before considering a downgrade (to test the patch)

Still no luck.

20:00:15 ~$ grep SystemCallFilter /usr/lib/systemd/system/fwupd.service 
SystemCallFilter=@basic-io @file-system @io-event @ipc @network-io @process @sync ioctl uname @raw-io splice @signal @timer @chown sysinfo madvise mremap

After reload, restart, and update, I still get the same error.

I don't know if the order makes a difference, I just added the new ones to the end of the line.

seth · 2024-04-25 09:08:07

https://github.com/fwupd/fwupd/commit/c … 237f498969

# the order of SystemCallFilter is important as the first encountered will take precedence and # will dictate the default action

You also seem to be missing "'vmsplice" and "copy_file_range"?

gkralik · 2024-04-25 09:14:03

So the correct line the upstream fix uses is now:

SystemCallFilter=@basic-io @file-system @io-event @ipc @network-io @process @sync @signal @timer @chown ioctl uname sysinfo madvise mremap splice vmsplice copy_file_range

If that still does not work, you can try setting

SystemCallErrorNumber=SIGSYS

and follow instructions from https://github.com/fwupd/fwupd/blob/mai … #L122-L124 to find out if any other syscall is missing from the allow list on your device.

iavr · 2024-04-25 18:49:53

seth wrote:

https://github.com/fwupd/fwupd/commit/c … 237f498969
# the order of SystemCallFilter is important as the first encountered will take precedence and # will dictate the default action
You also seem to be missing "'vmsplice" and "copy_file_range"?

That was it! It works now. Thanks for catching it.

Marking as solved.

Arch Linux

#1 2024-04-24 03:55:00

[SOLVED] Error updating firmware: "Error splicing file"

#2 2024-04-24 06:48:57

Re: [SOLVED] Error updating firmware: "Error splicing file"

#3 2024-04-24 07:24:48

Re: [SOLVED] Error updating firmware: "Error splicing file"

#4 2024-04-24 07:29:11

Re: [SOLVED] Error updating firmware: "Error splicing file"

#5 2024-04-24 07:47:18

Re: [SOLVED] Error updating firmware: "Error splicing file"

#6 2024-04-24 08:30:43

Re: [SOLVED] Error updating firmware: "Error splicing file"

#7 2024-04-24 12:56:33

Re: [SOLVED] Error updating firmware: "Error splicing file"

#8 2024-04-24 22:13:10

Re: [SOLVED] Error updating firmware: "Error splicing file"

#9 2024-04-24 22:22:47

Re: [SOLVED] Error updating firmware: "Error splicing file"

#10 2024-04-25 00:04:44

Re: [SOLVED] Error updating firmware: "Error splicing file"

#11 2024-04-25 09:08:07

Re: [SOLVED] Error updating firmware: "Error splicing file"

#12 2024-04-25 09:14:03

Re: [SOLVED] Error updating firmware: "Error splicing file"

#13 2024-04-25 18:49:53

Re: [SOLVED] Error updating firmware: "Error splicing file"

Board footer