Account Links: Cart | Your Account | Logout

Skip to content

Red Hat Knowledgebase

Red Hat Knowledgebase Search:

Updated Within the Last:

New Solutions within the last day New Solutions within the last week New Solutions within the last month

Browse by topics:


Click to View a Topic
Red Hat Enterprise Linux > AS/ES/WS v. 4 > Issue <<  30 of 628 >>

Solution Tools:


Email a Solution Postcard Printer version Submit a comment on this answer Update notifications Request an answer Back

Article Reference

Article ID: 7004
Last update: 11-16-07
Issue:
On my x86_64 based system, how do I fix up2date downloading packages but failing to install them because they are already installed?
Resolution:

Release Found: Red Hat Enterprise Linux versions 3 & 4

Symptom:
When running up2date previously, the program or system crashed during the "install" phase of the update. The uname -pi command shows the system is based on the x86_64 architecture. The rpm -qa --qf "%{NAME}\n"|sort|uniq -d command lists other entries besides kernel, kernel-smp, kernel-source, and gpg-pubkey. Your system is currently entitled, registered with Red Hat Network (RHN), and was otherwise able to use up2date.

It is assumed that you have enough disk space under /var/spool/up2date to hold the entire set of packages to be fixed. The entire set of packages will require about 3 gigabytes of space. However, the exact amount of space will vary based on the number and size of packages. Typically 500 megabytes to one gigabyte will be plenty.

Solution:
Generally, it is usually the RPM database which is out of step with the files on disk. Therefore, and fortunately, this is likely a recoverable situation. However, there is a chance of file and/or package corruption. This will depend on the specific set of conditions under which the crash occurred. There is also a small chance that the system may not be recoverable. In this case a full re-install is the only option Red Hat can provide support for. Either way, the first step is to put the database back into a "sane" state. Only then can further evaluations be made. You can attempt to fix the database by running the following commands as root:

Note: Most of these commands are long, typing them may be prone to error. Double check them first before pressing enter.

# rm -f /var/spool/up2date/*
# rpm -qa --qf "%{NAME},%{ARCH}\n"|sort|uniq -d|grep x86_64>/tmp/64bit.pkgs
# rpm -qa --qf "%{NAME},%{ARCH}\n"|sort|uniq -d|grep -v x86_64>/tmp/other.pkgs

Now, load /tmp/64bit.pkgs and /tmp/other.pkgs into your favorite text editor. Remove any lines pertaining to packages that should have multiple copies installed. For example: kernel,x86_64 , gpg-pubkey,noarch , etc. Then, use the following commands to download the packages, and fix the problem via a forced upgrade (which is safe in this context).

# cat /tmp/64bit.pkgs|cut -d "," -f 1|xargs up2date --get --arch=x86_64 
# cat /tmp/other.pkgs|cut -d "," -f 1|xargs up2date --get
# rpm -Uvh /var/spool/up2date/*.rpm --force
# rpm -Va > /tmp/verify.txt

Next, examine the /tmp/verify.txt file. This file indicates all the changes in status of any file tracked by a package in the RPM database. Some files are expected to be included in the list, however, everything else is best evaluated on a case-by-case basis. If you have a support subscription, we will gladly look through it for you to point out any problems we find.

Assuming that everything is back to normal, execute the up2date -p command to get the system's package list in sync with the RHN profile. A final run of up2date or up2date -uf will ensure that everything is updated.

Please note that this addresses a specific duplicate package problem and shouldn't be used otherwise.


How well did this entry answer your question?


good wrong incomplete out of date
Red Hat Enterprise Linux > AS/ES/WS v. 4 > Issue <<   30  of  628  >>