I'm using a Fedora Rawhide/40 KDE Plasma installation. I ran an offline upgrade using sudo dnf offline-upgrade download -x kernel\* --best --allowerasing sudo dnf offline-upgrade reboot I excluded updating from the 6.7.0 kernel to a 6.8 merge window kernel. I added --best --allowerasing to work around dnf problems with systemtap-client-5.0~pre16958465gca71442b-1.fc40.x86_64 and boost-system-1.83.0-0.fc40.x86_64 The update contained audit-4.0-1.fc40. audit-3.1.2-5.fc40 wasn't removed because of an audit-3.1.2-5.fc40.x86_64 preun scriptlet failure. Jan 19 17:38:05 dnf-3[960]: Running scriptlet: audit-3.1.2-5.fc40.x86_64 132/236 Jan 19 17:38:05 dnf-3[960]: Stopping logging: Jan 19 17:38:05 dnf-3[960]: Auditd is not running Jan 19 17:38:05 dnf-3[960]: error: %preun(audit-3.1.2-5.fc40.x86_64) scriptlet failed, exit status 2 Jan 19 17:38:05 dnf-3[960]: Error in PREUN scriptlet in rpm package audit Jan 19 17:38:05 dnf-3[960]: Cleanup : linux-firmware-20240115-1.fc40.noarch 133/236 Jan 19 17:38:05 dnf-3[960]: error: audit-3.1.2-5.fc40.x86_64: erase failed The transaction failed apparently due to the problem. Jan 19 17:38:25 dnf-3[960]: Failed: Jan 19 17:38:26 dnf-3[960]: audit-3.1.2-5.fc40.x86_64 Error: Transaction failed Jan 19 17:38:26 systemd[1]: dnf-system-upgrade.service: Main process exited, code=exited, status=1/FAILURE Jan 19 17:38:26 systemd[1]: dnf-system-upgrade.service: Failed with result 'exit-code'. Jan 19 17:38:26 systemd[1]: Failed to start dnf-system-upgrade.service - System Upgrade using DNF. Jan 19 17:38:26 systemd[1]: dnf-system-upgrade.service: Triggering OnFailure= dependencies. audit-3.1.2-5.fc40 and audit-4.0-1.fc40 both appeared to be installed on the boot after the update. rpm -q audit audit-3.1.2-5.fc40.x86_64 audit-4.0-1.fc40.x86_64 I tried sudo dnf remove audit-3.1.2-5.fc40.x86_64 which failed with the same error. ========================================================================================================================= Package Architecture Version Repository Size ========================================================================================================================= Removing: audit x86_64 3.1.2-5.fc40 @fedora 642 k Transaction Summary ========================================================================================================================= Remove 1 Package Freed space: 642 k Is this ok [y/N]: y Running transaction check Transaction check succeeded. Running transaction test Transaction test succeeded. Running transaction Preparing : 1/1 Running scriptlet: audit-3.1.2-5.fc40.x86_64 1/1 Stopping logging: Auditd is not running error: %preun(audit-3.1.2-5.fc40.x86_64) scriptlet failed, exit status 2 Error in PREUN scriptlet in rpm package audit Failed: audit-3.1.2-5.fc40.x86_64 Error: Transaction failed Reproducible: Always Steps to Reproduce: 1. Boot a Fedora Rawhide KDE Plasma installation 2. Log in to Plasma on Wayland 3. Start Konsole 4. sudo dnf offline-upgrade download -x kernel\* --best --allowerasing 5. sudo dnf offline-upgrade reboot Actual Results: Updating to audit-4.0-1.fc40 failed to remove audit-3.1.2-5.fc40 due to error: %preun(audit-3.1.2-5.fc40.x86_64) scriptlet failed, exit status 2 Expected Results: No errors should have happened. audit-rules.service failed to start on the next boot, but it might be a different problem. systemctl status audit-rules.service × audit-rules.service - Load Audit Rules Loaded: loaded (/usr/lib/systemd/system/audit-rules.service; enabled; preset: enabled) Drop-In: /usr/lib/systemd/system/service.d └─10-timeout-abort.conf Active: failed (Result: exit-code) since Fri 2024-01-19 17:39:23 EST; 47min ago Docs: man:auditctl(8) https://github.com/linux-audit/audit-documentation Main PID: 951 (code=exited, status=1/FAILURE) CPU: 92ms Jan 19 17:39:23 localhost.localdomain augenrules[980]: perm used without an arch is slower Jan 19 17:39:23 localhost.localdomain augenrules[980]: perm used without an arch is slower Jan 19 17:39:23 localhost.localdomain augenrules[980]: perm used without an arch is slower Jan 19 17:39:23 localhost.localdomain augenrules[980]: perm used without an arch is slower Jan 19 17:39:23 localhost.localdomain augenrules[980]: Error sending add rule data request (No such file or directory) Jan 19 17:39:23 localhost.localdomain augenrules[980]: There was an error in line 88 of /etc/audit/audit.rules Jan 19 17:39:23 localhost.localdomain augenrules[980]: No rules Jan 19 17:39:23 localhost.localdomain systemd[1]: audit-rules.service: Main process exited, code=exited, status=1/FAILURE Jan 19 17:39:23 localhost.localdomain systemd[1]: audit-rules.service: Failed with result 'exit-code'. Jan 19 17:39:23 localhost.localdomain systemd[1]: Failed to start audit-rules.service - Load Audit Rules.
What a mess. My rawhide system upgraded fine. There really isn't much that can go wrong in the %preun scriptlet: %preun %systemd_preun auditd.service # Prefer script because it waits for auditd to terminate if [ -e /usr/libexec/initscripts/legacy-actions/auditd/stop ] ; then /usr/libexec/initscripts/legacy-actions/auditd/stop else auditctl --signal stop fi I suppose I can add " || true" to the two commands so that it won't fail. And then push a -6 update to f39/38.
Oh, yes. The issue with audit.rules line 88 is a separate problem. Sounds like a watch on a file that doesn't exist or a typo in the path.
FEDORA-2024-9a859c5037 has been submitted as an update to Fedora 39. https://bodhi.fedoraproject.org/updates/FEDORA-2024-9a859c5037
FEDORA-2024-37ffaf9fc0 has been submitted as an update to Fedora 38. https://bodhi.fedoraproject.org/updates/FEDORA-2024-37ffaf9fc0
Thanks. The journal at the time of the preun error had Auditd is not running. /usr/libexec/initscripts/legacy-actions/auditd/stop exists on my system. So I guess auditd wasn't running at the point of the offline upgrade then /usr/libexec/initscripts/legacy-actions/auditd/stop had the error. auditd.service failed with a dependency error because of the audit-rules.service failure to start on the boot after the update. Line 88 of /etc/audit/audit.rules was -a always,exit -F path=/usr/lib64/mariadb/plugin/auth_pam_tool_dir/auth_pam_tool -F perm=x -F auid>=1000 -F auid!=unset -k privileged I ran a SCAP Workbench remediation script in 2020 which created audit rules files /etc/audit/rules.d/*.rules. /usr/lib64/mariadb/plugin/auth_pam_tool_dir/auth_pam_tool doesn't exist on my system now. I commented out that rule in /etc/audit/audit.rules and /etc/audit/rules.d/privileged.rules. auditd.service and audit-rules.service started normally after that. sudo dnf remove audit-3.1.2-5.fc40.x86_64 removed it without the error after auditd was running again. Should I make another report that audit-rules.service failed in that way or is that expected?
Regarding the line 88 rule, this is what's expected when there is problem with a rule. It's intent is to get your attention so it will be fixed. If you do not want it to fail in the future, you can copy /usr/share/audit-rules/12-ignore-error.rules to /etc/auditd/rules.d/ which will instruct auditctl to continue loading rules.
FEDORA-2024-9a859c5037 has been pushed to the Fedora 39 testing repository. Soon you'll be able to install the update with the following command: `sudo dnf upgrade --enablerepo=updates-testing --refresh --advisory=FEDORA-2024-9a859c5037` You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-2024-9a859c5037 See also https://fedoraproject.org/wiki/QA:Updates_Testing for more information on how to test updates.
FEDORA-2024-37ffaf9fc0 has been pushed to the Fedora 38 testing repository. Soon you'll be able to install the update with the following command: `sudo dnf upgrade --enablerepo=updates-testing --refresh --advisory=FEDORA-2024-37ffaf9fc0` You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-2024-37ffaf9fc0 See also https://fedoraproject.org/wiki/QA:Updates_Testing for more information on how to test updates.
FEDORA-2024-9a859c5037 has been pushed to the Fedora 39 stable repository. If problem still persists, please make note of it in this bug report.
FEDORA-2024-37ffaf9fc0 has been pushed to the Fedora 38 stable repository. If problem still persists, please make note of it in this bug report.