One of the newest things added to CentOS 7 is the capability to do an in place upgrade of CentOS 6.x to CentOS 7. In the past, the only official method of upgrading major versions of CentOS was to wipe and reinstall everything. Having said that, there were always processes you could follow with varying levels of success (based on straying from the official repositories and how customized your setup and package list was). We have run through this process now about a half dozen times, with varying levels of success, so let’s talk about some of the successes and failures.
Success and Failure Scenarios
Again, there are “ways” to get an upgrade done. In this post we will focus strictly on the official process that is supported by the CentOS maintainers. Given that, here is a quick list of upgrades that are likely to fail (all have failed in multiple ways for us):
- Straying from the Official Repositories – if you use EPEL, US, or any of the other unofficial but major repositories, your mileage may vary but expect to have issues. In the case of multiple servers that had fairly vanilla setups using packages from EPEL, all three failed with package consistency, dependency or conflict errors.
- Not making sure you are COMPLETELY current before running the preupgrade process. For some reason, running the preupgrade process before you are running CentOS 6.5 correctly (the latest and last 6.x version available as of the date of this article), subsequent upgrade attempts are likely to fail. There must be some upgrade list cached somewhere that isn’t properly removed/overwritten/regenerated after an update to 6.5 and then re-run. We will be doing further research on the subject, but beware.
- Third Party Packages Installed Outside Repositories – Of course there are a ton of reasons that you may have packages you downloaded and installed from various places outside of a repository, especially in Enterprise environments. Unfortunately, the upgrade process does not seem mature enough to always capture the dependencies and you either end up with a failed upgrade (at best) or a successful upgrade that has broken all the software you installed on it outside of those repositories and you have to manually fix the dependencies or configurations.
So what does work? Well, consistently, an installation at the latest CentOS 6.5 version with the standard (i.e. default) repositories as the only method of installing software works most of the time. I say most of the time because depending on WHAT software you have installed from those standard repositories, various things still fail. It’s pretty obvious that this is something entirely new for the CentOS maintainers and like anything else, is going through growing pains. Let’s ignore all this for now and walk through the official process of completing the upgrade.
So How Do I Do It?
On a freshly installed and then updated to latest version copy of CentOS 6.5, you run a program that will scan your system and determine what your upgrade status is (called the Preupgrade Assistant). Open a command prompt and type the following to see output similar to what we show below:
$ sudo preupg
Preupg tool doesn't do the actual upgrade.
Please ensure you have backed up your system and/or data in the event of a failed upgrade
that would require a full re-install of the system from installation media.
Do you want to continue? y/n
Gathering logs used by preupgrade assistant:
All installed packages : 01/10 ...finished (time 00:00s)
All changed files : 02/10 ...finished (time 00:48s)
Changed config files : 03/10 ...finished (time 00:00s)
All users : 04/10 ...finished (time 00:00s)
042/100 ...done (samba shared directories selinux)
043/100 ...done (CUPS Browsing/BrowsePoll configuration)
044/100 ...done (CVS Package Split)
|samba shared directories selinux |notapplicable |
|CUPS Browsing/BrowsePoll configuration |notapplicable |
|CVS Package Split |notapplicable |
Strangely enough, this particular process does nothing other than let you know of problems that might come up during the upgrade. It neither performs the upgrade nor helps you mitigate any of the issues that it finds. All of that is done using a tool still named after its Red Hat origins – redhat-upgrade-tool-cli. Be sure to start by importing the CentOS 7 key before you run it or it will fail, from a command prompt:
$ sudo rpm --import http://isoredirect.centos.org/centos/7/os/x86_64/RPM-GPG-KEY-CentOS-7
Now you can run the actual tool. As an example, the command I used to successfully upgrade my BASE CentOS 6.5 installation to CentOS 7 was as follows:
$ sudo /usr/bin/redhat-upgrade-tool-cli --network 7 --instrepo=http://mirror.centos.org/centos/7/os/x86_64
At this point, the upgrade process retrieved new Boot Images, downloads the necessary packages and then will ask for a reboot. During this process, if you get an error or the upgrade tool refuses to run, then one of two things is the likely cause: (1) You forgot to run the preupg tool or (2) It doesn’t recognize that you already did for some reason. If you don’t want to run the tool or it forgets that you already did, add the –force flag right as the first parameter and it should proceed normally at that point.
This is the right way forward for CentOS. The old paradigm of forcing a full reinstallation of the whole operating system and all packages and the headaches that comes with is too old guard for 2014. Baby steps have been taken to bring this upgrade process into the modern age and, although currently rife with problems and issues, the process has begun. Let us know in the comments below whether you have been successful in your efforts and what particular issues you may have dealt with when you took the plunge.