I notice that many fedora-ci.koji-build.installability.functional tests fail like in https://artifacts.dev.testing-farm.io/81fa0d39-cb75-4099-90c1-ad7c0706b0dc/:100:
Set selinux enforce to: 1 [...] Complete! Selinux policy: ---- type=AVC msg=audit(11/22/2023 09:10:13.155:1088) : avc: denied { map_read map_write } for pid=10733 comm=mandb scontext=system_u:system_r:mandb_t:s0 tcontext=system_u:system_r:init_t:s0 tclass=bpf permissive=0 Shared connection to 3.138.156.29 closed.
The logs do not mention any failure except the AVC. Probably when running mandb from an RPM file trigger which attempts to access an init script? I cannot reproduce it locally.
@ppisar thanks for filing, this is unfortunately a known issue caused by a systemd update I believe. More info on internal Slack and in following bugzillas:
https://redhat-internal.slack.com/archives/C04L304KVH9/p1700674280153949?thread_ts=1700656735.656049&cid=C04L304KVH9
https://bugzilla.redhat.com/show_bug.cgi?id=2250930 https://bugzilla.redhat.com/show_bug.cgi?id=2250935
Trying to talk to @zbyszek if we could start gating systemd on installability, which clearly shown the problem:
https://bodhi.fedoraproject.org/updates/FEDORA-2023-f631207330
The tests always fail. I tried to fix them, but there are very little docs, and the docs that are there are (at least for me) just incomprehensible. I asked in various places (e.g. https://pagure.io/fedora-project-config/issue/292), but that never went anywhere.
But if you can make the tests return useful results, I would be happy to look at them in the future.
It would also help a lot if the journal was saved. Ideally, as a standalone file produced by systemd-journal-remote. Having the messages in context and with metadata, and not just the console output, would it easier to diagnose failures.
systemd-journal-remote
Closing this in favor of #448
Metadata Update from @mvadkert: - Issue status updated to: Closed (was: Open)
I added the suggestion about saving journal there ...
Metadata Update from @mvadkert: - Issue status updated to: Open (was: Closed)
Reopening, the systemd problem still persists
So it looks like Anaconda packages are now affected by this:
BAD install: anaconda-0:41.17-1.fc41.x86_64 (selinux AVCs)
type=AVC msg=audit(05/21/2024 10:36:13.775:730) : avc: denied { read } for pid=3950 comm=systemd-ssh-gen name=vsock dev="devtmpfs" ino=386 scontext=system_u:system_r:init_t:s0 tcontext=system_u:object_r:vsock_device_t:s0 tclass=chr_file permissive=0 BAD install: anaconda-core-0:41.17-1.fc41.x86_64 (selinux AVCs)
type=AVC msg=audit(05/21/2024 10:36:35.832:1353) : avc: denied { read } for pid=4803 comm=systemd-ssh-gen name=vsock dev="devtmpfs" ino=386 scontext=system_u:system_r:init_t:s0 tcontext=system_u:object_r:vsock_device_t:s0 tclass=chr_file permissive=0
And similar: https://artifacts.dev.testing-farm.io/6bf474f1-56c9-4c1a-8f32-928023cdf205/ for https://src.fedoraproject.org/rpms/anaconda/pull-request/158#
We looked into this yesterday with jpopelka, but were not able to determine what is causing it.
Interesting enough, this really seems like an infra or test issues, rather than something specific to a new Anaconda version, as it passed for the 41.15 Anaconda currently in repos in the past.
But when I tried to trigger a test run using the 41.15 spec file and tarball, I got the same test failure:
https://src.fedoraproject.org/rpms/anaconda/pull-request/159 https://artifacts.dev.testing-farm.io/dbca7c0a-83dc-4214-ab15-fd136b03a5e8/
Log in to comment on this ticket.