Bug 2463540

Summary:	libseccomp (needed by udev) not included in initramfs
Product:	[Fedora] Fedora	Reporter:	Ian Pilcher <ipilcher>
Component:	dracut	Assignee:	Pavel Valena <pvalena>
Status:	CLOSED ERRATA	QA Contact:	Fedora Extras Quality Assurance <extras-qa>
Severity:	medium	Docs Contact:
Priority:	unspecified
Version:	44	CC:	daan.j.demeyer, dracut-maint-list, dtardon, fedoraproject, jamacku, jh.redhat-2018, lnykryn, msekleta, pvalena, suraj.ghimire7, systemd-maint, ubizjak, vmihalko, yuwatana, zbyszek
Target Milestone:	---	Keywords:	Regression, Security
Target Release:	---
Hardware:	Unspecified
OS:	Linux
Whiteboard:
Fixed In Version:		Doc Type:	---
Doc Text:		Story Points:	---
Clone Of:		Environment:
Last Closed:	2026-06-04 18:07:59 UTC	Type:	---
Regression:	---	Mount Type:	---
Documentation:	---	CRM:
Verified Versions:		Category:	---
oVirt Team:	---	RHEL 7.3 requirements from Atomic Host:
Cloudforms Team:	---	Target Upstream Version:
Embargoed:

Description Ian Pilcher 2026-04-28 19:15:07 UTC

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.

Comment 1 Ian Pilcher 2026-04-28 19:27:06 UTC

As a workaround, I created /etc/dracut.conf.d/udev-libseccomp.conf, with the following contents.

install_items+=" /usr/lib64/libseccomp.so.2 "

Comment 2 Ian Pilcher 2026-05-02 14:10:08 UTC

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.

Comment 3 Zbigniew Jędrzejewski-Szmek 2026-05-04 05:58:14 UTC

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.

Comment 4 Ian Pilcher 2026-05-04 13:22:07 UTC

(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!

Comment 5 Ian Pilcher 2026-05-14 14:28:05 UTC

Pavel -

What are your thoughts on this?

Comment 6 Frantisek Sumsal 2026-05-26 09:12:32 UTC

*** Bug 2481404 has been marked as a duplicate of this bug. ***

Comment 7 Zbigniew Jędrzejewski-Szmek 2026-05-28 09:27:06 UTC

> 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.

Comment 8 Zbigniew Jędrzejewski-Szmek 2026-05-28 11:52:07 UTC

https://github.com/systemd/systemd/pull/42366 to downgrade the warning.

Comment 9 Fedora Update System 2026-06-04 16:52:04 UTC

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

Comment 10 Fedora Update System 2026-06-04 18:07:59 UTC

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.