I have been having difficulties upgrading internet-disconnected RHEL-7 servers for over 2 months.
When I first started to patch the servers (plural) in question the yum update had a refined/restricted list of RPMs associated with kernel-3.10.0-1160.45.1.el7.x86_64 and all of the other dependency packages. The machine froze hard and my only option was to reboot the machine.
The machine is a VMware VM and it does not update any packages at all now.
During the latest attempt I am certain that the Yum command (environment) got broken. Here is what I see as a result of executing yum list installed:
There was a problem importing one of the Python modules required to run yum. The error leading to this problem was:
/lib64/libxml2.so.2: file too short
Please install a package which provides this module, or verify that the module is installed correctly.
It's possible that the above module doesn't match the current version of Python, which is:
2.7.5 (default, Aug 13 2020, 02:51:10)
[GCC 4.8.5 20150623 (Red Hat 4.8.5-39)]
If you cannot solve this problem yourself, please go to the yum faq at:
http://yum.baseurl.org/wiki/Faq
I typed the text verbatim; however, I believe the url is incorrect as provided in the output from the command yum list installed.
If yum cannot even list all of the installed packages properly, how am I supposed to “install a package which provides this module”? Which module, libxml2.so.2?
# yum whatprovides /lib64/libxml2.so.2
libxml2-2.9.1-6.el7_9.6.x86_64 : Library providing XML and HTML support
Repo : @updates
Matched from:
Filename : /lib64/libxml2.so.2
So you can probably download that rpm from rhel7 updates and install using rpm -ivh (not yum!)
Thank you, the package seems to be installed, but the file appears to be disassociated from the package for some reason.
My result looks like the following:
libxml2-2.9.1-6.el7_9.6.x86_64 : Library providing XML and HTML support
Repo : installed
Matched from:
Filename : /lib64/libxml2.so.2
Do you guys have any ideas? This particular machine has got some screwy problems with it that occurred while I was applying specifically-targeted packages to include libxml2 and kernel (and other kernel package dependencies).
Somehow during one of our maintenance windows the yum install of packages (several in the list) hung really bad during the installation of the kernel package itself. It was the last package in the list during the yum install execution.
This was the complete list of all the packages installed at the time:
I had them all in the same directory under my homedir, using the following command while I was sitting in the homedir:
yum install *.rpm
I did it this way because we are disconnected from the internet (yay) and do not have a standalone YUM repository on the same network (brilliant, I know).
Which means that the all files on system that are from same package as file /lib64/libxml2.so.2 are identical to what is in that package (attributes and all).
The verbose rpm -Vvf /lib64/libxml2.so.2 lists those files.
The file is actually a symlink:
[CentOS 7]$ ls -l /lib64/libxml2.so.2
lrwxrwxrwx. 1 root root 16 Oct 27 09:34 /lib64/libxml2.so.2 -> libxml2.so.2.9.1
But since it points to real file from same package and that is intact (per ‘rpm -V’), it is.
If yum/dnf transaction is interrupted, then that can leave duplicates: new package has been installed (somewhat), but old one hasn’t been cleaned out completely.
yum-utils has utility ‘package-cleanup’ that can list/clean duplicates (in Alma too).
I wonder which yum-operations do require libxml? If only repo access, then some local commands might run:
yum check
package-cleanup --dupes
With ‘rpm’ one can list installed packages too: rpm -qa libxml2\*
Sorry, I need clarity of the explanation you provided. Do you mean that all of the other files provided by the package libxml2-2.9.1-6.el7_9.6.x86_64.rpm will also not be owned by a package and therefore rpm -Vf other_files_from_same_package will not have a result either? That would make sense.
Having never used package-cleanup I have to ask, will it simply execute or does it need confirmation to complete execution?
Also, is the yum check, a preemptive step preparing the “yum environment” to know what to clean up?
As for the rpm command, I was aware of that. Also, I used rpm -qa | egrep libxml2 and got as listing of the exact same packages.
In rpm -Vf /lib64/libxml2.so.2 the option -V (–verify) is action and the -f /lib64/libxml2.so.2 select-option.
Its result is same as rpm -V $(rpm -qf /lib64/libxml2.so.2) – verify all files of package “libxml2”.
The default for verify is to list only changes. As man rpm says it:
Verifying a package compares information about the installed files in the package with information about the files taken from the package metadata stored in the rpm database. Among other things, verifying compares the size, digest, permissions, type, owner and group of each file. Any discrepancies are displayed.
The ‘package-cleanup’ is a script that calls ‘yum’ and yum does ask for confirmation. man package-cleanup
man yum writes:
check Checks the local rpmdb and produces information on any problems it finds. You can pass the check command the arguments “dependencies”, “duplicates”, “obsoleted” or “provides”, to limit the checking that is performed (the default is “all” which does all).
In other words, some functions of ‘package-cleanup’ probably just run ‘yum check’.
whilst the packages might be installed some files are obviously corrupted (file too short), so you’ll have to reinstall them manually without using yum, so use rpm -Uvh on the rpm’s in your homedir and pray they were the only files that were corrupted.
i suspect you ran out of disk space when you did the original kernel update.
This is a great suggestion @sej7278. I had considered a yum install --force; however, I think you are right executing an rpm -Uvh libxml2 would help to fix the libxml2 package - I hope.
As for the disk space, I checked disk space before executing the upgrade(s) and I had plenty of space. We have 100s of GBs on many of the filesystems and /tmp has over 100GB from what I can remember (I am at home presently). I do not mean to be argumentative, just merely point out the fact that I did check storage availability before starting.