Fedora Account System
Red Hat Associate
Red Hat Customer
I'm not sure if this is new with Fedora 44, but after upgrading a couple of systems, I see this message in both of their logs. /usr/lib/systemd/system/systemd-udevd.service:56: System call bpf cannot be resolved as libseccomp is not available, ignoring: Operation not supported libseccomp is not present in the initramfs. I suspect that this is happening because udevd uses dlopen()s it, rather than linking it directly, so dracut doesn't realize that udevd needs it. Reproducible: Always Steps to Reproduce: 1. Upgrade to Fedora 44 (or probably install a new Fedora 44 system). 2. Boot. 3. Check logs (sudo journalctl -b). Actual Results: libseccomp not included in initramfs. udev not properly sandboxed. Expected Results: Something (not sure what) needs to tell dracut to include the library, so that udev sandboxing will work.
As a workaround, I created /etc/dracut.conf.d/udev-libseccomp.conf, with the following contents. install_items+=" /usr/lib64/libseccomp.so.2 "
I just checked, and libseccomp is included in the initramfs on Fedora 43, where is is directly linked by /usr/lib/systemd/systemd-udevd. Marking this as a security-related regression.
I'm not sure if it *should* be included. The initramfs is a limited environment and there's a tradeoff between the additional protection and saving the space in the initrd. But either way, this is a decision to be made by the creator of the initrd, dracut in this case.
(In reply to Zbigniew Jędrzejewski-Szmek from comment #3) > I'm not sure if it *should* be included. The initramfs is a limited > environment and there's a tradeoff between the additional protection and > saving the space in the initrd. But either way, this is a decision to be > made by the creator of the initrd, dracut in this case. Is it really a dracut decision, though? I feel like, in general, it's the job of a component that needs to live in the initrd to *tell* dracut if it needs a particular library that it dlopen()s. How are the dracut developers supposed to keep up with the list of libraries that a particular component dlopen()s? If the decision is ultimately made that systemd-udevd in the initramfs doesn't need the same level of sandboxing that it does when running from the root filesystem, then something needs to done about the error message. Let's please not turn Fedora into Kubernetes!
Pavel - What are your thoughts on this?
*** Bug 2481404 has been marked as a duplicate of this bug. ***
> it's the job of a component that needs to live in the initrd to *tell* dracut if it needs a particular library that it dlopen()s. True. This information is available in two ways: $ rpm -q --recommends systemd | grep bpf libbpf.so.1()(64bit) libbpf.so.1(LIBBPF_0.4.0)(64bit) It is is also possible to call dlopen-notes: $ dlopen-notes /usr/lib64/systemd/libsystemd-shared-261.so -f bpf { "bpf": { "description": "Support firewalling and sandboxing with BPF", "sonames": { "libbpf.so.1": "suggested", "libbpf.so.0": "suggested" } } } In both cases the UX is not great because the dependencies might be declared on a different component pulled in through a dependency. In this case, we need libbpf for the filter used by systemd for systemd-udev.service, which is part of systemd-udev.rpm. systemd-udev.rpm has Requires on systemd.rpm, which declares the Recommends… If dnf is used, it takes case of the transitive dependencies, but if this is done manually, the recursion must be done manually too. We hope to build better tooling in the future.
https://github.com/systemd/systemd/pull/42366 to downgrade the warning.
FEDORA-2026-4280f7beb8 (systemd-261~rc3-1.fc45) has been submitted as an update to Fedora 45. https://bodhi.fedoraproject.org/updates/FEDORA-2026-4280f7beb8
FEDORA-2026-4280f7beb8 (systemd-261~rc3-1.fc45) has been pushed to the Fedora 45 stable repository. If problem still persists, please make note of it in this bug report.