Comments

338 Comments

Thanks @mgoodwin! As three weeks is still quite far out, do you plan to remove this erratum, so that CIs stop tripping over this?

karma

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.

karma

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.

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.

[1] https://github.com/cockpit-project/bots/pull/2265

karma

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

Why did that lower the version number? The previous release was 0.20.3, this is now 0.20.1. dnf won't downgrade by default. Can you please fix the version number?