The following page is to cover items of concern that people find when they upgrade from a release to another. Please add sections below as needed.
General considerations regarding migration:
- A clean install is generally strongly preferred over an upgrade.
- Be sure you have a good backup before doing anything to a system.
- It is often helpful to have a bootable linux system on a separate set of partitions or better yet a separate disk. This can serve as a fall-back or rescue system, as well as an on-line backup. Disk space is cheap compared to sysadmin time.
- You may want to upgrade the operating system parts of the filesystem and leave user directories, such as /home in place. If you do leave the old user home directories in place expect some problems with the GNOME/KDE menus and other desktop items. It may be preferable to create new user accounts and mount the old directories somewhere else in the filesystem for reference, copying, or linking user's material after the migration.
- If you decide to do an upgrade anyway...
- Clean up as much as possible before the upgrade, removing any RPMS you do not need, or that you know will be obsoleted.
- Do an anaconda upgrade. Yum upgrades, or "live" upgrades with other package managers, MAY be possible but are often more problematic - particularly with regard to glibc and kernel/drivers. Fatal yum dependency conflicts have been reported by multiple people attempting yum upgrades from CentOS 4.4 to 5.
Upgrades from systems other than the latest CentOS4.4 (WhiteBox, RHEL, TaoLinux, ...) may be possible but will also require more gyrations. See see HowTos/MigrationGuide or MigrationGuide (needs updating).
- After upgrading use "rpm -qa --last" to find packages that were not updated. See sections below for examples.
- Remove any packages that are not needed.
- If you find left-over packages that have higher version numbers than the CentOS5 packages use "rpm -Uvh --oldpackage foo-1.2-3.i386.rpm ... " (or possibly the ugly "rpm -Uvh --force ..." in a pinch) to get CentOS5 versions of packages that may have had lower version numbers to replace the obsolete packages.
- Find/build EL5/CentOS5 versions of remaining required/desired packages. ATrpms, RPMforge (Dag/Dries), and EPEL (Fedora Extras for EL) all have EL5 packages. Things that can't be found there can often be rebuilt from FC6/7 src.rpm packages, or perhaps even the FC binaries used directly if you are feeling lucky (not recommended). Always beware when using/mixing 3rd-party repos. The yum protectbase and priorities plugins are your friends.
- Enjoy!
- If upgrading, consider first "cloning" the system and upgrading the clone.
- As root, create the new partitions as desired - root, boot, home, swap - assume for example /dev/hde1 ,2, 3, 4...
- Make file systems
# mke2fs -j -L /clone_boot /dev/hdb1 # mke2fs -j -L /clone /dev/hde2 # mkswap -L SWAP-hde3 /dev/hde3 # mke2fs -j -L /clone_home /dev/hde5 # mke2fs -j -L /clone_data /dev/hde6
- Make a mountpoint for the clone, say /clone
# mkdir /clone
- Mount the partition that is to be the new root on /clone, make other mount points, mount all new partitions
# mount /dev/hde2 /clone # mkdir /clone/boot /clone/home /clone/data # mount /dev/hde1 /clone/boot # mount /dev/hde5 /clone/home # mount /dev/hde6 /clone/data
- Do the clone operation
# tar clf /boot | tar xf - -C /clone # tar clf /home | tar xf - -C /clone # tar clf / | tar xf - -C /clone
- Edit /etc/fstab, /boot/grub/grub.conf adding entries for the clone partitions and boot stanzas
- Edit /clone/etc/fstab, /clone/boot/grub/grub.conf adding entries for the original partitions and boot stanzas
- Test-boot both systems before proceeding.
- Perform the upgrade on the clone system and write grub to the boot partition rather than the MBR
- Boot the original OS and update the grub boot stanza for the new OS - formerly clone.
- Boot the new OS. Optionally, make the new OS grub the default (preferably after testing)
# grub-install /dev/hda (or /dev/sda)