Comments
martinpitt
Thanks @mgoodwin! As three weeks is still quite far out, do you plan to remove this erratum, so that CIs stop tripping over this?
Same pmlogger service regression as in Fedora 34:
# systemctl start pmlogger
Job for pmlogger.service failed because the service did not take the steps required by its unit configuration.
Oct 11 04:30:00 fedora-35-127-0-0-2-2201 systemd[1]: Starting Performance Metrics Archive Logger...
Oct 11 04:30:00 fedora-35-127-0-0-2-2201 pmlogger[3290]: /usr/libexec/pcp/lib/pmlogger: Warning: Performance Co-Pilot archive logger(s) not permanently enabled.
Oct 11 04:30:00 fedora-35-127-0-0-2-2201 pmlogger[3290]: To enable pmlogger, run the following as root:
Oct 11 04:30:00 fedora-35-127-0-0-2-2201 pmlogger[3290]: # /usr/bin/systemctl enable pmlogger.service
Oct 11 04:30:00 fedora-35-127-0-0-2-2201 systemd[1]: pmlogger.service: Failed with result 'protocol'.
Oct 11 04:30:00 fedora-35-127-0-0-2-2201 systemd[1]: Failed to start Performance Metrics Archive Logger.
Oct 11 04:30:01 fedora-35-127-0-0-2-2201 systemd[1]: pmlogger.service: Scheduled restart job, restart counter is at 1.
systemctl enable --now pmlogger works, so somehow the "not enabled" warning breaks the service.
Completely breaks pmlogger.service:
# systemctl start pmlogger
Job for pmlogger.service failed because the service did not take the steps required by its unit configuration.
# systemctl status pmlogger
× pmlogger.service - Performance Metrics Archive Logger
Loaded: loaded (/usr/lib/systemd/system/pmlogger.service; disabled; vendor preset: enabled)
Active: failed (Result: protocol) since Mon 2021-10-11 04:25:21 UTC; 4s ago
Docs: man:pmlogger(1)
Process: 3953 ExecStart=/usr/libexec/pcp/lib/pmlogger start-systemd (code=exited, status=0/SUCCESS)
Main PID: 3953 (code=exited, status=0/SUCCESS)
CPU: 110ms
Oct 11 04:25:19 fedora-34-127-0-0-2-2201 systemd[1]: Starting Performance Metrics Archive Logger...
Oct 11 04:25:19 fedora-34-127-0-0-2-2201 pmlogger[3545]: /usr/libexec/pcp/lib/pmlogger: Warning: Performance Co-Pilot archive logger(s) not permanently enabled.
Oct 11 04:25:19 fedora-34-127-0-0-2-2201 pmlogger[3545]: To enable pmlogger, run the following as root:
Oct 11 04:25:19 fedora-34-127-0-0-2-2201 pmlogger[3545]: # /usr/bin/systemctl enable pmlogger.service
Oct 11 04:25:19 fedora-34-127-0-0-2-2201 systemd[1]: pmlogger.service: Failed with result 'protocol'.
Oct 11 04:25:19 fedora-34-127-0-0-2-2201 systemd[1]: Failed to start Performance Metrics Archive Logger.
Oct 11 04:25:19 fedora-34-127-0-0-2-2201 systemd[1]: pmlogger.service: Scheduled restart job, restart counter is at 1.
We found that this makes the UI less discoverable, due to the UI review not being implemented enough yet. Hence, let's not push this version to stable yet.
We found that this makes the UI less discoverable, due to the UI review not being implemented enough yet. Hence, let's not push this version to stable yet.
This actually breaks mounting NTFS devices in udisks (and thus desktops), as ntfs-3g is now uninstallable: https://bugzilla.redhat.com/show_bug.cgi?id=2001755
Unfortunately that already landed in stable.
This is -1 after all -- see https://bugzilla.redhat.com/show_bug.cgi?id=2001713#c8 . The "ntfs-3g" package is not installable, this is tracked in https://bugzilla.redhat.com/show_bug.cgi?id=2001755 now.
Dropping the ntfs-3g dependency was an explicit decision in https://bugzilla.redhat.com/show_bug.cgi?id=2001713#c5 -- retracting my -1.
The ntfs-3g update breaks udisks: https://bugzilla.redhat.com/show_bug.cgi?id=2001713 .
I re-triggered the gating test, as the initial run was completely bogus.
@jforbes: If FIPS is not something that Fedora officially supports, I am also happy to disable our FIPS tests there, and only run them on RHEL (it also breaks there, but maybe a bit less often). Indeed there are not very many hits for "Fedora FIPS", so maybe we are being overly expectant here? (Then again, this time around it was not the cockpit team but someone else who filed the F33 bug, so at least one other person cares 😀). Thanks!
This broke booting with FIPS. Just saying that this regression has been known for two months..
Over the years I've seen dozens of FIPS boot failures. Would it be possible to include this into the gating tests?
Sorry, false alarm - this update actually fixes this long-standing severity parsing bug: https://github.com/PackageKit/PackageKit/issues/268
This caused a regression with changelog severity parsing [1], but two days over a weekend was not enough time to catch this. I'll report to bugzilla instead.
Somehow this got stuck i "pending", even though both gating tests and user feedback said :+1. I tried "publish to testing" again.
We just caught this new regression in Cockpit's CI:
audit: type=1400 audit(1623381106.279:360): avc: denied { getattr } for pid=1784 comm="mdadm" path="/dev/dma_heap" dev="devtmpfs" ino=127 scontext=system_u:system_r:mdadm_t:s0-s0:c0.c1023 tcontext=system_u:object_r:dma_device_dir_t:s0 tclass=dir permissive=0
Given how new SELinux updates can potentially break everything, can you please let new versions simmer in updates-testing for at least two days or so? Updating within less than 24 hours is just not enough time to spot regressions.
Still doesn't work. Upgrading from Fedora 34 picks up the higher version number:
Upgrading:
conmon x86_64 2:2.0.28-0.2.dev.git551605f.fc35 fedora 53 k
containernetworking-plugins
x86_64 1.0.0-11.1.git8de0287.fc35 fedora 9.0 M
containers-common noarch 4:1-19.fc35 fedora 60 k
crun x86_64 0.20.3-0.12.git8d6a8b5.fc35 fedora 173 k
Confirmed to work against FreeiPA 4.9.7, fixes the getcert failure. Thanks!