Dnf upgrade to kernel 5.14.0-687.52.1.el9_8 does not run kernel-install

Support
1

I had a couple of issues with the upgrade to kernel-5.14.0-687.52.1.el9_8.
Firstly, although dnf installed the upgrade and there were no errors reported, the kernel did not appear in the boot options. I had to manually run kernel-install to overcome this. What would have caused this?

Secondly, I am getting a number of messages about duplicate entries in my log files, e.g. “error: syslog:11 duplicate log entry for /var/log/secure”. I am using rsyslog and none of the configuration files appear to have been changed.

Thirdly, the system became stuck during the shutdown phase when rebooting after the upgrade leading to a swag of errors in the logfiles - possible cause of #2 above?

2

Hello,

You could try checking the three issues separately.

For the missing kernel boot entry, please check whether the RPM scriptlet failed during the DNF transaction:

dnf history info
grep -iE ‘kernel|scriptlet|posttrans|error|warning’ /var/log/dnf*.log

Since manually running kernel-install worked, this may have been a failure during the RPM post-transaction step.

For the “duplicate log entry for /var/log/secure” message, this looks like a separate logrotate configuration issue rather than an rsyslog problem. Red Hat documents the same type of error here:

You can check for duplicate definitions with:

grep -Rns ‘/var/log/secure’ /etc/logrotate.conf /etc/logrotate.d/
logrotate -d /etc/logrotate.conf

I would therefore investigate this separately from the kernel-install issue.

For the shutdown hang, I would also treat that as a separate issue and check the previous boot journal:

journalctl -b -1 -e

The logrotate duplicate entry is unlikely by itself to explain the shutdown hang.

Thanks.

3

Hi redadmin, Thanks for the suggestions.

  1. No errors logged in dnf.log

  2. Found the source of the duplicate logrotate errors, I had both a syslog and an rsyslog file in /etc/logrotate.d pretty much doing the same thing but this has only started recently so I am not sure what has triggered it. I have merged these into one rsyslog file and logrotate seems happy again, using
    logrotate -d /etc/logrotate.conf 2>&1 | less

  3. Looked at the boot journal and did not see anything much there, but will check again if this continues to happen.

4

Thanks for the update. Good to hear the logrotate issue is resolved.

Since there were no errors in the DNF log, I’d just keep an eye on the kernel-install issue and collect the journal/transaction details if it happens again.