In troubleshooting a problem a colleague noticed that there were md5sum differences in the files of identical systems:
ServerOne # md5sum /lib64/libc-2.12.so
ServerTwo # md5sum /lib64/libc-2.12.so
Analyzing a hex dump of the .so files showed cyclical differences at matching locations. This is where I began helping to look at the problem. After walking through the above (these files were the focus of an application error) I suggested we do a yum reinstall. This resulted in different md5sums from those listed above. The cyclical and matching locations are the link locations in the hex dump, as expected there are differences in the hex locations between systems.
After a little research I found the reason the md5sum’s don’t match is yum install uses prelink. ‘prelink’ is a program that modifies ELF shared libraries and ELF dynamically linked binaries used by yum, therefore there would be differences in the md5sum even on identical systems.
To see the actual md5sum of the package before prelink is run, use the following command:
# prelink -y /lib64/libc-2.12.so | md5sum
I ran this on the two systems in question and they match. The files are the same on each systems, therefore this was a red hearing and the search continues.
Very occasionally installing a package or updates with yum can have unexpected results. Fortunately yum provides the ability to roll back anything it installs. Here is an example of what these commands look like:
# yum history
Loaded plugins: package_upload, product-id, search-disabled-repos, security, subscription-manager
ID | Login user | Date and time | Action(s) | Altered
11 | root <root> | 2016-12-16 13:20 | Install | 8
10 | root <root> | 2016-12-16 10:38 | Install | 1
9 | root <root> | 2016-12-16 08:05 | Install | 1
8 | root <root> | 2016-12-15 15:37 | Install | 1
7 | root <root> | 2016-12-15 13:29 | Install | 10
6 | root <root> | 2016-12-15 12:55 | Install | 5 <
5 | root <root> | 2016-12-08 14:51 | I, O, U | 381 >E
4 | root <root> | 2016-12-08 14:45 | Install | 4
3 | root <root> | 2016-12-08 14:12 | I, U | 32 EE
2 | root <root> | 2016-12-08 14:11 | Install | 1
1 | System <unset> | 2016-12-08 13:50 | Install | 644
To reverse any of these yum actions simply issue the command:
# yum history undo "#"
Where the trailing “#” is the ID number from the yum history output.
I ran across the following yum error after migrating a system from being a client of Satellite 5.6 to Satellite 6.1. First here is the error:
# yum update
Loaded plugins: package_upload, priorities, rhnplugin, search-disabled-repos, security, subscription-manager
There was an error communicating with RHN.
RHN Satellite or RHN Classic support will be disabled.
Please run rhn_register as root on this client
Error Class Code: 9
Error Class Info: Invalid System Credentials.
An error has occurred while processing your request. If this problem
persists please enter a bug report at bugzilla.redhat.com.
If you choose to submit the bug report, please be sure to include
details of what you were trying to do when this error occurred and
details on how to reproduce this problem.
Setting up Update Process
rhel-6-server-rpms | 2.0 kB 00:00
rhel-6-server-satellite-tools-6.1-rpms | 2.1 kB 00:00
No Packages marked for Update
This left me scratching my head for a few and a quick search didn’t produce much so I thought I should document this for prosperity.
The problem was with the contents of the file /etc/yum/pluginconf.d/rhnplugin.conf
Part of my transition is running this command:
sed -i -e 's/enabled=1/enabled=0/g' /etc/yum/pluginconf.d/rhnplugin.conf
The problem was unlike all of my other systems, this file must have been edited because instead of containing “enabled=1” it contained “enabled = 1”
To correct that I modified my sed command to ignore white space:
sed -i -e 's/enabled\s*=\s*1/enabled=0/g' /etc/yum/pluginconf.d/rhnplugin.conf
More details can be found using the yum.conf man page.
Hope that is helpful.
Pulling packages from multiple sources can lead to problems. If you are running rhel and have epel enabled an update could inadvertently pull down a newer version from the wrong repository. This doesn’t always cause a problem, but it can. If you need to tfind all the epel packages on your system, here is how you: List all packages installed from repo “X”
yum list installed | grep @epel
Pardon the humor. Just a collection of useful yum commands that are useful to have around but I don’t always remember off the top of my head. I’ll be adding to this post over time.
How to list the files installed by a yum package
You will need ‘repoquery‘ which is part of ‘yum-utils‘. If you don’t have ‘repoquery‘ install it first, then start using it:
# yum install yum-utils
# repoquery --list *package*
How to list/install a package from a specific repository
# yum repolist
# yum --disablerepo="*" --enablerepo="repo-name-here" list available
# yum --disablerepo="*" --enablerepo="repo-name-here" install package-name
Doing an update I ran across this error:
Error: Multilib version problems found. This often means that the root
cause is something else and multilib version checking is just
pointing out that there is a problem. Eg.:
You could try using --skip-broken to work around the problem
You could try running: rpm -Va --nofiles --nodigest
Of course the first command that is suggested is a bad idea, I mean talk about denial! I ran the second, which did nothing, still got the same problem. So I did a little digging and these two yum commands seem to have corrected the problem, though they do run for a while (10-30 minutes)
# yum check
# yum distro-sync
Update (08 Oct 2015):
Hunting down some system package inconsistencies and I figured out how to list all RPM packages installed from Repo X:
yum list installed | grep @epel