rhupgrade.pl - Script to assist you in hand made RedHat upgrades
-v Print verbose/debug info -ud Use the 'Distribution' field to help detect RedHat packages -ubh Use the 'Build Host' field to help detect RedHat packages oldpkglist List of packages available for the RH version that is currently installed on your machine. newpkglist List of packages available for the RH version you wish to upgrade to
--version Prints version and date, and exits -h/--help Prints this help screen and exits
In order to find out whether an installed package is from RedHat, or if
it's a ``contrib'' package, by default the 'Vendor' field checked.
Unfortunately, some upgrade packages (at least for 4.2) do not contain the
vendor information (they were either done too fast, while responding
quickly to a security problem in some package, or they may have been made
by a newly hired rookie
Therefore, if you find out that some official RedHat packages end up being detected as contrib packages, try -ud to look for ``Red Hat Linux'' in the distribution field (This is only moderately effective because some RH 4.2 packages do not carry that information, and newer RH releases don't mention 'RHL' in the distribution field (5.0 just says Hurricane)). This is why you can use -ubh which will look for a build host in the redhat.com domain (this seems to catch everything, but if someone makes contrib packages on a machine.redhat.com, they will be mistaken for official RedHat packages).
oldpkglist and newpkglist are both expected to have one package name per line (with their full name). The list should look like this:
ElectricFence-2.0.5-4.i386.rpm ImageMagick-3.8.3-1.i386.rpm (...) One way to make the newpkglist file is by doing something like this: (open ftp session to site that has the RPMS packages of the new distrib) (cd to RPMS directory) ftp> ls . /tmp/tmppkglist output to local-file: /tmp/tmppkglist? y 200 PORT command successful. 150 Opening ASCII mode data connection for /bin/ls. 226 Transfer complete. ftp> 221 Goodbye. moremagic:$ cat /tmp/tmppkglist | cut -c55- > /tmp/pkglist
Once you have the list, keep in mind that the script has to be run on the machine you intend to upgrade (because it launches an ``rpm -qa'' to find out which packages you are currently using)
A redhat package looks like this: package_name-pkgversion_number-redhat_release_number.arch.rpm
The package version number is assigned by the author of the program, whereas the redhat release number is typically the number of times the package had bugs or configuration problems removed.
If the input file is pkglist, the following files will be created (in the same directory than where pkglist is):
Note that this is not equivalent to the list of new packages in the new release as it won't show packages that are already installed on your machine (because you have a similar contrib package, or because you ran the program after upgrading some of your packages). If you were looking for such a list, you should look at pkglist_new.
If the -o option wasn't used, what would have ended up in this file will go in pkglist.notinstalled instead.
You have: bash-2.0-1, and the new list has: bash-1.14.7-1.i386.rpm You have: lynx-2.7.1-1, and the new list has: lynx-2.6-2.i386.rpm You have: zgv-2.7patched-1, and the new list has: zgv-2.7-5.i386.rpm
I expect that you know how to generate a script that would launch a bunch
rpm -Uvh ftp://path/file.rpm from one or several of the generated lists. If you don't, then you probably
shouldn't use rhupgrade as it might introduce some subtle problems that you
may have a hard time fixing.
Note that it is actually a better idea to download the packages you intend to update first, and then run rpm on them. The reason is that some packages depend on other ones and you will eventually try to upgrade a package that depends on one you don't have. This will cause the upgrade to fail, and you'll have to download the packages again, until you get all the dependencies right.
If I didn't scare you off from using this program yet, here are an few examples of things that can happen:
I did a partial upgrade of RH 4.1 to 4.2 with the help of this program. I upgraded pam, and one of its changes was to replace /etc/pam.conf by /etc/pam.d/ and one file for each pam aware program. This turned out to break su, as it is bundled with sh-utils and that su would not find any valid line in the recently emptied /etc/pam.conf. I had to upgrade sh-utils to get a new version of su that had a /etc/pam.d/su file.
This is however nothing compared to what can potentially happen to you if you do a partial upgrade to RH 5.0. For instance, if upgrade to glibc, but don't upgrade SysVinit, your system will not boot because you would have an /sbin/init linked against libc5, and unless don't have a /usr partition, init won't be able to find libc.so.5, and your system won't boot (unless you specify init=/bin/sh on the lilo prompt). Oh, and did I mention the package containing kerneld was renamed from modules to modutils, so if you don't look at the list of new packages, and install this one, possibly along with a few other ones, you may have some problems when booting later.
You can find more tips on upgrading from RH 4.x to 5.0 later in this document
Anyway, the important thing to remember is that if you do partial upgrades, use your brain and don't go to RH or me crying for help if everything breaks :-)
NOTE: You should not have to, but if you really want to be on the safe side, you may want to switch to single user while doing the upgrade of certain packages, or kill some specific daemons (crond comes to mind) while they are being upgraded (some programs could get confused if they are upgraded while they are running)
I had rather painful upgrade from RH 3.0.3 to RH 4.0 because I had a heavily customed system, and fixing everything from the very limited root shell you have during the floppy upgrade was not fun.
This program was written to facilitate upgrades ``by hand'' grabbing just the packages you need, and using command-line RPM to upgrade the packages you want to upgrade (all this on a live system, without rebooting).
Why would you want to use it?
You should know that upgrading to 5.0 by hand is not trivial, but if you decide to go ahead, here are some tips:
:-D) fired up, as well as a few midnight commanders (if you are, like me, a fan of that great tool). The reason for this is that during the upgrade, you may reach a state where you won't be able to launch any more of those, until you're finished upgrading
rpm --nodeps -U rpm-2.4.10-1glibc.i386.rpm rpm -U ld.so-1.9.5-5.i386.rpm ldconfig-1.9.5-2.i386.rpm rpm -e locale NetKit-B rpm -U setup-1.9.1-1.noarch.rpm glibc-2.0.5c-10.i386.rpm rpm -U info-3.9-7.i386.rpm rpm -e linuxthreads-devel quota db-devel rpm -U binutils-188.8.131.52.1-1.i386.rpm rpm -i glibc-devel-2.0.5c-10.i386.rpm rpm -e libc-debug rpm -i glibc-debug-2.0.5c-10.i386.rpm rpm -U pam* rpm -i netkit-base-0.10-5.i386.rpm rpm -U tcl*-8.0* tk-8.0-12.i386.rpm expect-5.24-12.i386.rpm
From there, upgrading the other packages should be easier. You can put the
list of packages in a file, and do something like this:
for i in `cat /tmp/packagestoupgrade` ; do echo $i; rpm -U $i; done
Don't forget to install the basesystem package. It doesn't do anything, but
it seems important according to the description. I am not quite sure what
it's for, but it souds important
rpm --provides -qilp *.rpm > /tmp/liston the list of packages, so that you can easily refer to that file for dependencies, and finding out what package some program/file migrated to
More seriously, those lists are for informative use only, this script should not be a substitute for your own good jugement, but it's proven to be very useful for me.
This script also expects that information in RPMs is accurate, and if not, the results are undefined. However, there is a workaround for packages from RedHat that don't have the Vendor field filled correctly: try the -ud and -ubh flags.
Note also that this script expects that the new list actually is from a distribution more recent that your current one, and the old list (if specified). If by any chance the new list has older packages that the ones you have (like running against the 4.2 list of packages when you have 4.2 + upgraded packages from the redhat site), the script won't know about it, and will list old packages as packages you should upgrade to.
As a last test, a simple regression test would be to do something like this:
moremagic:$ wc -l pkglist.* 3 pkglist.contribclash 55 pkglist.new 165 pkglist.notinstalled 1 pkglist.notrpm 3 pkglist.release 243 pkglist.same 13 pkglist.version 483 total moremagic:$ wc -l pkglist 483 pkglist
(Now you know why some files have a '.' as a separator, and the other ones
have a '_'
I won't old my breath, but if you use this script, I'd appreciate a little
Email, just to make sure that I'm not releasing this, and writing all this
documentation for nothing