This article comes with a HUGE warning. This was written using beta tools available from here: http://dev.centos.org/centos/6/upg/x86_64/Packages/
I will likely update this article when these tools are no longer in beta and when I perform this on my more complicated production server. Right now I’m testing these packages and this method on a relatively simple CentOS 6 test server I have at work.
My test server has the basics on it like Apache, PHP, NFS, VNC, Samba and Gnome. It is a vSphere VM with 2vCPUs, 4GB of RAM and the storage is back ended on a NetApp via NFS.
I pieced this together using the references at the bottom of the post. This will probably work for upgrading RHEL6 to RHEL7 as well but you’ll need to figure out the mirror information. I don’t have access to RHEL repos.
TAKE A FULL SYSTEM BACKUP BEFORE FOLLOWING THIS GUIDE
- Download the upgrade packages from http://dev.centos.org/centos/6/upg/x86_64/Packages/
12345[root@localhost temp]# wget -c "http://dev.centos.org/centos/6/upg/x86_64/Packages/preupgrade-assistant-1.0.2-33.el6.x86_64.rpm"[root@localhost temp]# wget -c "http://dev.centos.org/centos/6/upg/x86_64/Packages/preupgrade-assistant-contents-0.5.13-1.el6.noarch.rpm"[root@localhost temp]# wget -c "http://dev.centos.org/centos/6/upg/x86_64/Packages/preupgrade-assistant-ui-1.0.2-33.el6.x86_64.rpm"[root@localhost temp]# wget -c "http://dev.centos.org/centos/6/upg/x86_64/Packages/python-rhsm-1.9.7-1.el6.x86_64.rpm"[root@localhost temp]# wget -c "http://dev.centos.org/centos/6/upg/x86_64/Packages/redhat-upgrade-tool-0.7.22-1.el6.noarch.rpm"
- Install the tools. My server needed some pre-reqs which yum took care of
1[root@localhost temp]# yum install *.rpm
- Run the upgrade tool
1[root@localhost temp]# preupg
- The tool will now warn you that you should have taken a full system backup. Hopefully you did. Press ‘y’ to contiune
- The tool will now run a bunch of tests to determine if there are any blockers for an upgrade. This took about 10 minutes on my system. Once the tool completes it’s assessment you’ll find an upgrade report in ‘/root/preupgrade-results/’
- Review the files in the report. Mine came out with no results…. I take this to mean it found nothing wrong with an in place upgrade…. or there is a bug in the tools. The readme included this description of each file and status descriptions:
123456789101112131415161718192021222324252627282930313233343536373839404142434445464748495051525354555657585960616263646566676869707172737475767778/root/preupgrade file&directory structure------------------------------------This directory contains the data from the last preupgrade assistant run.Files:result.html - File with final migration assessment report in human readableform (we are sorry for "listing" functionality only)result.xml - File with final migration assessment report in machinereadable formREADME - this fileresults.tar.gz - Tar ball with all files in directory /root/preupgradeDirectories:cleanconf - directory with all user-modified configuration files, which werechecked for the compatibility by preupgrade-assistant. These filescan be safely used on RHEL-7 system (some of these files may needpostupgrade.d scripts execution)dirtyconf - directory with all user-modified configuration files, which were notchecked for the compatibility by preupgrade-assistant. These mayrequire admin review after the RHEL-7 installation/upgrade.kickstart - directory which contains various files useful for generatingkickstart for cloning this system. Some of the files in thisdirectory may give administrator the guidance what was not handledby rhelup (and will need some additional actions). See README filein the kickstart directory for the file descriptions.postupgrade.d - contains various scripts which are supposed to be executedAFTER the upgrade to RHEL-7. These scripts should NEVER be usedon RHEL-6 system.RHEL6_7 - just "debugging" directory - will be removed later. Ignore, unless you'll see some "Error" plugin exit status.Possible check exit codes explanation-------------------------------------Every single plugin has its own exit code. Administrator needs to checkat least those with FAIL result before using inplace upgrade. Results FIXEDshould be checked after the inplace upgrade - to finish the RHEL-7 migrationproperly.The possible exit codes are:* PASS = everything is fine, no incompatibility/issue detected by this checker* FAIL = some incompatibility/issue that needs to be review by admin was detected.FAIL doesn't necessarily mean that inplace upgrade will fail, but mayresult in not 100% functional system* FIXED = some incompatibility was detected, but preupgrade-assistant was ableto find automated solution. Some of the fixes may require runningpostupgrade.d scripts after the upgrade. Fixed configs are availablein /root/preupgrade/cleanconf directory. preupgrade-assistant doesn'thandle the fixes automatically at the moment!* INFORMATIONAL = nice to have information for admins (e.g. removed optionsin some common tools which may cause malfunctions of their scripts)* NOT_APPLICABLE = package which should be tested by the check is notinstalled on the system (test therefore doesn't make sense)* ERROR = shouldn't occur, does usually mean error in the preupgrade-assistantframework. All such errors should be reported to Red Hatpreupgrade-assistant team.In place upgrade risk explanations-----------------------------------There are several levels of inplace upgrade risks. Any level higher than"slight" means you will get not 100% functional upgraded system, althoughinplace upgrade tool "rhelup" may pass.The available risk assessment levels are:* None - Default. It can be used as an indicator for some checks. It is notnecessary to enter these values.* Slight - We assessed this field and have not found any issues. However,there is still some risk that not all variants have been covered.* Medium - It is likely that the area causes a problem in case of the inplaceupgrade. It needs to be checked by the administrator afterthe inplace upgrade and after the system has been monitored forsome time.* High - The inplace upgrade can't be used safely without the administrator'sassistance. This typically involves some known broken scenario,existing 3rd party packages. After the administrator manually fixesthe issue, it may be possible to perform the inplace upgrade, but itis not recommended.* Extreme - We found an incompatibility which makes the inplace upgradeimpossible. It is recommended to install a new system with the helpof preupgrade-assistant remediations.
- Since my report didn’t lead me to believe there were any issues that had to be dealt with pre-upgrade I went for it. First I had to import the repo key and then I ran the upgrade
12[root@localhost temp]# rpm --import http://mirror.its.sfu.ca/mirror/CentOS/7/os/x86_64/RPM-GPG-KEY-CentOS-7[root@localhost temp]# redhat-upgrade-tool --network 7.0 --instrepo http://mirror.its.sfu.ca/mirror/CentOS/7/os/x86_64/ --cleanup-post --reboot --force
Note: I had to add “–force” to the above command. It kept telling me I had not run ‘preupg’ which I had”
- After running the above command things started happening. From what I’ve read online this process will take up to 90 minutes while it downloads updates, creates a new boot image, reboots the server and performs the upgrade. The system will automatically reboot when it’s ready.On my system spec’d out as I listed above on a 300mbit internet connection the upgrade process took about 45 minutes.
That’s it! After a few reboots I ended up with a CentOS 7 machine…. with a few issues.
In my case Gnome would load a black screen and there were about 164 CentOS 6 packages left that were not upgraded to their equivalent CentOS 7 packages which caused ‘yum update’ to not work anymore citing dependency issues.
I also had a package, pywebkitgtk, which I had installed that was causing ‘yum update’ to not function properly after adding the EPEL Beta 7 Repo. A quick ‘yum remove pywebkitgtk’ and then ‘yum update’ fixed that.
Apache wasn’t very happy either. The config file needed a lot of work.
On my server there ended up being about 134 CentOS6 packages left over which may or may not cause conflicts in the future.
While this technically worked I’m going to recommend side-by-side upgrades to a fresh CentOS 7 server as the better way to do this. I also believe it is the recommended best practice.