Please forgive me if I missed something, but I've searched all over in hopes of finding something documented on a procedure to upgrade a Centos 3.4 system to the beta. I've got the DVD burned and am testing the process on VMWare. All I could figure out how to do was install over the existing partition without formatting, but this was quasi-disastrous so I 'reverted' my VMWare drive to the prior state. Is there some way to reconfigure yum.conf, GPG keys, etc. so that it will pull down the changes? Or, is there a way to 'upgrade' the system using the CD as a source? Any help would be appreciated. I was hoping it was as simple as the upgrade from 3.3 to 3.4, but I couldn't find anything out there.
Thanks,
Mike
On Fri, 2005-01-21 at 23:58 -0800, Michael Taylor wrote:
Upgrading via yum is very hard, and the results are not very good ... there are many things that change to vastly different versions. I can almost guarantee you will have some kind of issues after an upgrade with yum.
The best (and most consistent) way to upgrade is to use anaconda, at the ISO linux bootprompt on the CD use the command:
linux upgradeany
The anaconda routine produces the most consistent upgrades ... BUT, if you have anything outside the standard CentOS 3.x installed (like DAGs yum repo stuff), you may have issues. ---------------------------------------- RedHat discourages upgrades, from the RedHat RHEL 4 beta install manual:
Although upgrades are supported by the Red Hat Enterprise Linux family on x86 processors, you are more likely to have a consistent experience by backing up your data and then installing this release of Red Hat Enterprise Linux 3.93 over your previous Red Hat Enterprise Linux installation.
This recommended reinstallation method helps to ensure the best system stability possible.
For more information about re-installing your Red Hat Enterprise Linux system, refer to http://www.redhat.com/docs/wp/
If you currently use Red Hat Enterprise Linux 3 on an x86 system, you can perform a traditional, installation program-based upgrade.
However, before you chose to upgrade your system, there are a few things you should keep in mind:
* Individual package configuration files may or may not work after performing an upgrade due to changes in various configuration file formats or layouts.
* If you have one of Red Hat's layered products (such as the Cluster Suite) installed, it may need to be manually upgraded after the Red Hat Enterprise Linux upgrade has been completed.
* Third party or ISV applications may not work correctly following the upgrade.
Upgrading your system installs the modular 2.6.x kernel as well as updated versions of the packages which are currently installed on your system.
The upgrade process preserves existing configuration files by renaming them with an .rpmsave extension (for example, sendmail.cf.rpmsave). The upgrade process also creates a log of its actions in /root/upgrade.log.
Caution
As software evolves, configuration file formats can change. It is very important to carefully compare your original configuration files to the new files before integrating your changes.
Note
It is always a good idea to back up any data that you have on your systems. For example, if you are upgrading or creating a dual-boot system, you should back up any data you wish to keep on your hard drive (s). Mistakes do happen and can result in the loss of all of your data.
Some upgraded packages may require the installation of other packages for proper operation. If you choose to customize your packages to upgrade, you may be required to resolve dependency problems. Otherwise, the upgrade procedure takes care of these dependencies, but it may need to install additional packages which are not on your system.
Depending on how you have partitioned your system, the upgrade program may prompt you to add an additional swap file. If the upgrade program does not detect a swap file that equals twice your RAM, it asks you if you would like to add a new swap file. If your system does not have a lot of RAM (less than 128 MB), it is recommended that you add this swap file.
If you still choose to perform a traditional upgrade, type the following command at the installation boot prompt:
linux upgradeany
On Sat, 2005-01-22 at 04:13 -0600, Johnny Hughes wrote:
Substitute CentOS-4Beta and CentOS-3.x and I agree with that statement.
I agree with that too ... it applies to CentOS upgrades to CentOS-4.0
I, like redhat, also think that backing up your data and doing a reinstall and then moving your data over is the best and most reliable solution.
Johnny Hughes wrote:
My 2c is that you'll spend so much time trying to figure out how to do it--or having to fix things that don't work right later--that it would have taken less time to have just done a fresh install of the new OS and set up everything you had on the old version. You might try mkkickstart if you just want to get the same set of packages, it seems to work for some people but I haven't had much luck with it. Usually, I just make a list of packages on the old and new "machine" and compare and install packages until I have basically the same set of packages installed, something like:
rpm -q -a \ | awk '{n=split($0,a,"-"); delete a[n]; delete a[n-1]; for (j in a) printf "%s-",a[j]; printf "\n"}' \ | sort -u > old.txt
Do the same to make new.txt on the new machine, then
comm -23 old.txt new.txt | awk '{print substr($0,1,length($0)-1)}' > want.txt
If you just want to get user files, since it's a VM, usually I set up /home as a separate virtual disk, then you can just make a new VM and use the old disk file for /home with the new VM. You can even put the virtual disk for the old "/" as an extra disk and mount it as say /r2 or /old to copy over settings from /etc and so on. If you want /usr/local or /opt or whatever, just rsync it from the old root.
--jonathan
Thanks everyone for your responses. I am not running anything out of the ordinary here, so I should have no problem re-installing. I was just hoping to avoid the manual merge of configuration files. The tip on using a separate virtual disk for home directories was also brilliant. Thanks!!
Thanks again,
Mike
-
Johnny Hughes -
Jonathan Dill -
Michael Taylor