Dnf update has broken dnf

Good day to all.
First post here. Running Rocky 8.9. On Feb 12 2024, I had packages waiting for update, and so updated. But now, when I try to install packages by yum or dnf, it appears that the package manager is broken. I have included image to packages that were included in the update.
This is the error I now see

dnf[342390]: segfault at 20 ip 00007ff020ba5e57 sp 00007ffd97b84568 error 4 in libc-2.28.so[7ff020ada000+1bc000]

and

Running transaction
  Preparing        :                                                                                                                                                                                                                                                       1/1
  Installing       : cronie-anacron-1.5.2-8.el8.x86_64 [==                                                                                                                                                                                                               ] 1/3Segmentation fault (core dumped)

Anyone experienced this before?

I’d check if dnf itself was corrupted somehow. Try ‘rpm —verify dnf’?

Thanks for response Brian.

[ruser@host ~]# rpm --verify dnf
[ruser@host ~]# echo $?
0


All looks good regards to a corrupted dnf.

Looks like the problem starts when rpm is updated.
This updates these packages. After this, yum/dnf gives the errors I posted above

[root@rr-rocky8-template ~]# yum update rpm
Last metadata expiration check: 0:08:05 ago on Thu 22 Feb 2024 11:44:47 AM GMT.
Dependencies resolved.
=======================================================================================================================================
 Package                                     Architecture            Version                             Repository               Size
=======================================================================================================================================
Upgrading:
 python3-rpm                                 x86_64                  4.14.3-28.el8_9                     baseos                  154 k
 rpm                                         x86_64                  4.14.3-28.el8_9                     baseos                  543 k
 rpm-build-libs                              x86_64                  4.14.3-28.el8_9                     baseos                  156 k
 rpm-libs                                    x86_64                  4.14.3-28.el8_9                     baseos                  347 k
 rpm-plugin-systemd-inhibit                  x86_64                  4.14.3-28.el8_9                     baseos                   78 k

Narrowed down the issue to librpm.so but not sure how to fix this

==2326== Process terminating with default action of signal 11 (SIGSEGV)
==2326==  Access not within mapped region at address 0x50
==2326==    at 0x4C3E656: strlen (vg_replace_strmem.c:501)
==2326==    by 0x7C6483C: vfprintf (in /usr/lib64/libc-2.28.so)
==2326==    by 0x7D384BC: __vsnprintf_chk (in /usr/lib64/libc-2.28.so)
==2326==    by 0x50DF7F6: rpmlog (in /usr/lib64/librpmio.so.8.2.0)
==2326==    by 0x15CE3F68: ??? (in /usr/lib64/rpm-plugins/selinux.so)
==2326==    by 0x4EA46CB: ??? (in /usr/lib64/librpm.so.8.2.0)
==2326==    by 0x4E7F9B0: rpmPackageFilesInstall (in /usr/lib64/librpm.so.8.2.0)
==2326==    by 0x4E835B4: ??? (in /usr/lib64/librpm.so.8.2.0)
==2326==    by 0x4E83C06: ??? (in /usr/lib64/librpm.so.8.2.0)
==2326==    by 0x4E98B99: ??? (in /usr/lib64/librpm.so.8.2.0)
==2326==    by 0x4E9F6C3: rpmtsRun (in /usr/lib64/librpm.so.8.2.0)
==2326==    by 0x4E929AF: ??? (in /usr/lib64/librpm.so.8.2.0)

This has been solved by

  1. adding tsflags=nocontexts to /etc/dnf/dnf.conf
  2. installing rpm-plugin-selinux

Even though selinux was in Permissive mode, calls to rpm were being denied because of the above plugin missing.

In a test environment, I managed to narrow down the problem to where rpm was trying to install packages.
A colleague of mine then downloaded a package and attempted to install in verbose mode using rpm -vv
It is here the calls to selinux were being seen and denied.

1 Like

Seems strange, since on all my systems this package is installed by default. So kind of wondering why on your system it wasn’t installed/been removed by someone or something? Would be good to go through the log files to find out when the package was removed, since an update being applied to the system also shouldn’t remove this but rather update what was installed.

Yeah. Just checked back all packages installed/uninstalled/upgraded via yum history. Seems rpm-plugin-selinux was never installed. But had never affected previous upgrades or selinux which is running in Permissive mode

Sidenote: I’ve seen cloud images, where none of the image creation is in dnf history.
Likewise, direct use of ‘rpm’ does not show in dnf history.

Maybe, but luckily for me, these images are created by myself using packer and so I can see everything that has been installed or uninstalled if i use yum history info <id>

Hmm, how come that the backtrace shows /usr/lib64/rpm-plugins/selinux.so then? This file is provided by rpm-plugin-selinux. It would have been interesting to see the output of rpm -qf /usr/lib64/rpm-plugins/selinux.so before installing the plugin. Or was the backtrace produced at a later time?