When trying to run fwupdmgr, it hangs. journalctl: Nov 12 12:07:55 lap dbus-daemon[433]: [system] Activating via systemd: service name='org.freedesktop.fwupd' unit='fwupd.service' requested by ':1.104' (uid=0 pid=38477 comm="fwupdmgr refresh> Nov 12 12:07:55 lap systemd[1]: Starting Firmware update daemon... Nov 12 12:07:55 lap fwupd[38487]: Failed to load daemon: syscall filtering is configured but not working Nov 12 12:07:55 lap systemd[1]: fwupd.service: Main process exited, code=exited, status=1/FAILURE Nov 12 12:07:55 lap systemd[1]: fwupd.service: Failed with result 'exit-code'. Nov 12 12:07:55 lap systemd[1]: Failed to start Firmware update daemon. Nov 12 12:08:20 lap dbus-daemon[433]: [system] Failed to activate service 'org.freedesktop.fwupd': timed out (service_start_timeout=25000ms) This is on a systemd gentoo. fwupd was emerged with [ebuild R ] sys-apps/fwupd-2.0.1::gentoo USE="amdgpu archive bash-completion cbor gnutls lzma nvme policykit spi systemd uefi -amt -bluetooth (-elogind) -fastboot -flashrom -gtk-doc -introspection -logitech -minimal -modemmanager -sqlite -synaptics -test -tpm" PYTHON_SINGLE_TARGET="python3_12 -python3_10 -python3_11 -python3_13" 4855 KiB The same problem also existed in 1.9.x fwupd, but was definitely fixed in 1.9.20, see my comment 1 in bug 931500 and upstream bug https://github.com/fwupd/fwupd/issues/7144 However, the meson.build commit applied to fix 7144 is present in the current gentoo 2.0.1 build, so this is most likely "same error message, but different reason".
Downgraded to 1.9.24, this one works fine.
See also https://github.com/fwupd/fwupd/issues/8078
Unfortunately, I haven't been able to reproduce this on any of my devices. Did you restart the fwupd service before running fwupdmgr? Does fwupdtool work?
Given that error message comes from the daemon, that was a dumb question. Could you please attach `emerge --info`?
Created attachment 908818 [details] emerge --info
Created attachment 908819 [details] Kernel .config Kernel .config is from 6.11.8, fwupd error was with 6.11.6 or 7, but I didn't change the config since then.
(In reply to John M. Harris, Jr. from comment #3) > Unfortunately, I haven't been able to reproduce this on any of my devices. > > Did you restart the fwupd service before running fwupdmgr? Does fwupdtool > work? I will re-emerge 2.0.1 und test fwupdtool tomorrow.
Did some testing with 2.0.1: 1.) The fwupd daemon is auto-started by systemd on demand, not when booting: As soon as I invoke fwupdmgr on the command line, the error message mentioned above appears in the syslog. Nothing about fwupd in the syslog before that. 2.) fwupdtool works without problems, at least for the commands refresh and get-updates. 3.) fwupdmgr refresh and get-updates also work without problems after I manually start /usr/libexec/fwupd/fwupd in another terminal as root before invoking fwupdmgr. And /usr/libexec/fwupd/fwupd outputs only expected warnings to its terminal, nothing related to syscall filtering. This could indicate that something is wrong with Gentoo's fwupd.service?
Created attachment 908890 [details] fwupd.service as installed by emerge on my Gentoo system
Could you please try with USE=flashrom? Removing that USE flag from my Dell systems, I can reproduce this.
(In reply to John M. Harris, Jr. from comment #10) > Could you please try with USE=flashrom? Removing that USE flag from my Dell > systems, I can reproduce this. flashrom does not make a difference for me: It fails with and without flashrom. But I analyzed the problem: On startup, the fwupd daemon actually checks that syscall filtering is working: It tries a mlock system call which should be filtered (i.e. should fail), and if that mlock succeeds, it terminates itself with "Failed to load daemon: syscall filtering is configured but not working". fwupd relies on systemd for syscall filtering. However, syscall filtering in systemd is optional: It is only compiled into systemd with USE=seccomp. Without USE=seccomp, systemd silently ignores syscall filtering and lets all syscalls pass through. On all my systems, systemd is built without seccomp. So there are two different ways to solve the problem (tried both, both work for me): * Either make the fwupd ebuild depend on systemd[seccomp] (I don't like that solution: Don't force security onto systems which do not want or need to be secure). * Or (if systemd is built without seccomp) modify fwupd's meson-build (or the final fwupd.service), removing the line Environment="FWUPD_SYSCALL_FILTER=systemd". Without that line, fwupd does not check syscall filtering on startup. Perhaps the fwupd ebuild should also get a USE=seccomp flag?
Two upstream patches (data/meson.build and meson_options.txt), fix the problem for me, see https://github.com/fwupd/fwupd/issues/8078 The patches introduce a new bool meson variable systemd_syscall_filter. It needs to be set to false in the ebuild if systemd does not have syscall filtering. At the first glance, the following changes are needed if those patches are accepted upstream: * Introduce a new USE seccomp in fwupd, valid only if USE systemd is set * Depend on systemd[seccomp] if USE seccomp is set * Set meson systemd_syscall_filter to true or false depending on USE seccomp
fwupd-2.0.2 is out now
(In reply to Joakim Tjernlund from comment #13) > fwupd-2.0.2 is out now fwupd-2.0.3 is out
The bug has been closed via the following commit(s): https://gitweb.gentoo.org/repo/gentoo.git/commit/?id=daa6d2e14eeed0862de714a73cf480ba0a5e2407 commit daa6d2e14eeed0862de714a73cf480ba0a5e2407 Author: John M. Harris Jr. <johnmh@johnmh.me> AuthorDate: 2024-12-10 07:04:06 +0000 Commit: Sam James <sam@gentoo.org> CommitDate: 2024-12-13 09:34:22 +0000 sys-apps/fwupd: add 2.0.3 Introduces USE=seccomp for systemd seccomp filtering. Closes: https://bugs.gentoo.org/943319 Signed-off-by: John M. Harris Jr. <johnmh@johnmh.me> Signed-off-by: Sam James <sam@gentoo.org> sys-apps/fwupd/Manifest | 1 + sys-apps/fwupd/fwupd-2.0.3.ebuild | 190 ++++++++++++++++++++++++++++++++++++++ 2 files changed, 191 insertions(+)
