Hi Erwin,
Thank you, that helps a lot.
From the information you provided, it appears we are looking at an exceptional combination of events:
- A breaking change was introduced upstream in systemd as part of the Rocky Linux 9.8 update.
dnf-automaticinstalled operating system updates independently of NS8’s update workflow.- The node rebooted before Core 3.19.1 had been installed.
Under those circumstances, the node could reach a state where Rocky Linux was already updated while the compatibility fix contained in Core 3.19.1 was still missing, triggering the issue you experienced.
The important point is that the conflict is not related to the time of day when the updates run. Setting dnf-automatic to 06:30 and apply-updates.timer to run overnight does not avoid the problem. The issue is that the two update agents see different DNF repository contents and make independent update decisions.
With an active subscription, only apply-updates.timer is designed to coordinate NS8 Core, applications, and operating system updates so that they are applied in the intended order. In contrast, dnf-automatic only sees the operating system updates and can install them before the corresponding NS8 Core update becomes available or is scheduled for installation.
Until we release a Core update that detects and blocks this situation, I recommend disabling dnf-automatic and any Cockpit-managed automatic DNF updates. With an active subscription, operating system updates are already handled by apply-updates.timer, so keeping both mechanisms enabled can lead to unexpected results.
Thank you for helping us investigate this. Your findings, together with the other report, are helping us better understand the conditions that triggered the problem.
Best,
Davide