< Extras
Fedora Legacy RPM Upgrade
Due to the rpm deadlock problems that occurs too frequently with the rpm that originally shipped in Red Hat Linux 8.0 and 9, Fedora Legacy for these two distributions requires the upgrade of rpm as a pre-requisite for using our tools. The rpm-4.1.1-1.8x and rpm-4.2-1 upgrades are "official" versions built and distributed by rpm.org , and extensively tested since April 2003. fedora.us has resigned the rpm.org binaries for distribution and placed them into the "legacy" channel of these distributions, along with fedora.us package management tools.
This means that you CAN benefit from the Legacy's security updates channel and avoid the RPM upgrade, but only if you exclude yourself from the "legacy" channel. By not upgrading your RPM, your RPM WILL LOCKUP PERIODICALLY, you cannot benefit from the fedora.us tools, and you are also unsupported by the Fedora Legacy team.
As the first step in configuring Fedora Legacy for your Red Hat Linux 8.0 or 9 server, you must use the following procedure in order to manually & safely upgrade rpm. After this point you can use the automatic package management tools which are known to be very reliable after the rpm upgrade.
HOWTO Upgrade RPM Safely
1. First you must make sure that all existing programs that touch the rpm database are not currently running, or will not run automatically during your RPM upgrade. Simultaneous access by multiple programs could possibly cause a deadlock during upgrade. While this is not known to be fatal, it is annoying.
- Kill the RHN panel monitor that runs automatically in your systray.
- Close all RPM related programs like Synaptic or Add/Remove Applications.
- Disable service rhnsd with service rhnsd stop. You may want to disable it completely on RH8 since it is no longer useful with RHN. Use chkconfig rhnsd off to prevent it from starting automatically during bootup.
- Some automatic update programs like yum may be scheduled, so temporarily disable cron with service crond stop. After your upgrade do not forget to turn it back on with service crond start.
- Use commands like ps -ef |grep rpm to confirm that there are no remaining rpm processes running. Look for other programs like apt-get, yum, or rhn-applet that might be stuck from previous rpm lockups. If there appear to be stuck processes, read the bottom of this section of this page RPM Deadlock Recovery.
- After you have done the above to prevent other programs from accessing the RPM database, download all packages for your distribution.
- RH8 rpm* popt*
- [1]
- RH9 rpm* popt*
- [2]
- Use rpm -Fvh rpm*i386.rpm popt*i386.rpm and it will upgrade only the rpm packages that you already have installed.
- If it did not lockup, then your RPM upgrade is probably successful. Continue reading [wiki:Self:Extras/FedoraLegacyHOWTO FedoraLegacyHOWTO] for the next steps in Fedora Legacy configuration and configuring your automatic package management tool.
RPM Deadlock Recovery
This is the procedure to properly recover from a RPM deadlock condition. You can simply reboot to recover, but that is generally a poor solution when the following quick method exists. 1. Use commands like ps -ef |grep rpm to see if there exist stuck processes of rpm, rhn-applet, gnorpm, or other processes that use the rpm database. You should be sure that rpm did indeed lockup and it is not just being slow. This is because killing rpm when it really didn't lockup is quite bad. Also read this page for more information about detecting true deadlocks.
- [3] Here is one example where rhn-applet managed to trigger the deadlock. The strace shows the characteristic FUTEX_WAIT when rpm gets stuck. This is a strong indicator that the deadlock did occur.
- After you have confirmed that a lockup occurred, then you must kill that process. Most of the time regular kill (SIGTERM) is insufficient in killing these processes, so you must use kill -9 (SIGKILL).
- Use rm -f /var/lib/rpm/* in order to erase the lockfiles so rpm can again run.
rpm --rebuilddb is almost never necessary if you follow the above procedures. There is some disagreement about this, but this post definitively answers this question.