By: Matt Micene, Solutions Architect
This is the follow up to the preupgrade-assistant post, start there to get the full story.
In our last episode, we took at look at the evaluation we’d need to do in order to upgrade a RHEL 6 system to RHEL 7 using the new tooling. Here, we’re going to look at the prep steps and the actual upgrade process.
In the first post, I linked to the instructions on the Customer Portal but also make sure to review the Supported Use Cases document. This is a living document that lists the various considerations for upgrading. Two things of note that I think need clarification.
First is the “Source to Upgrade” row. The process for an upgrade requires you to be on the latest version of RHEL 6. So while the minimum supported version is 6.5, the first step is bringing it up to 6.6.
Second, the “Packages/Groups” row. This is a yum Group not an anaconda profile. If you’re using kickstarts this may not be as big a deal, but if you’re installing via the DVD and selecting a profile you’ll wind up with more groups and packages installed than may be supported. It’s not necessarily a major problem but understand that you may wind up in an unsupported situation.
Something that has changed since the last post, you now need the Extras and the Optional channel for the tooling to work, the OpenSCAP tools have been relocated.
# rhn-channel --add --channel rhel-x86_64-server-extras-6
# rhn-channel --add --channel rhel-x86_64-server-optional-6
Caveats out of the way, let’s see how an upgrade went. The VM I’ll be using has a (fairly) clean bill of health from the preupgrade-assistant. There’s a lot of cautious HIGH results, mainly stemming from changes in default service states from RHEL 6 to RHEL 7. Since I’m contrary (and trying to mimic real world conditions here) I’m going to be using a VM that’s registered to a Satellite 5 server not to Subscription Manager. I’m also not paying attention (at my own risk, your mileage may vary, contents under pressure do not expose to direct flame) to the restrictive Group list and running with an Anaconda Web Server profile.
# yum -y update
There’s a bug in the latest version of the preupgrade-assistant tool that has an issue with multiple versions of kernels (don’t worry Red Hat’s already on it). If you see an EXTREME error with a note about this not being the latest version of RHEL 6 but you’ve done the yum update step above, this could be the issue. I’ll need to pull everything but the latest kernel package. Then I can install the tool and proceed with the other prework.
# rpm -q kernel
# rpm -e kernel-2.6.32-431.el6.x86_64
# yum -y install redhat-upgrade-tool
For systems registered with Satellite we need to disable the RHN yum plugin before moving forward, so edit the config file and change the ‘enabled’ value.
# vim /etc/yum/pluginconf.d/rhnplugin.conf
enabled = 0
gpgcheck = 1
As I said, reviewing the list of results, there’s some false positives about non-Red Hat packaging and HIGH warnings about changes to default services in RHEL 7 from RHEL 6. The only warning I care about from the preupgrade-assistant run is the SELinux issue, so I’ll run the command listed in the Solution section.
# semodule -r sandbox
OK, this host is all prep’d for an upgrade.
For the RHEL 7 repository source, I’m going to attach the 7 Server ISO to the VM. You can set up a repo accessible on the network or (if you have room) copy the ISO contents to the system you’re upgrading. Since I’m using a local copy of install media, I need to make sure to mount it first so the tool can find it. Then I can run the redhat-upgrade-tool.
If you’d like to see a debug log you can use the ‘-d’ and ‘–debuglog’ options to create a log in specific location. I’m using the ‘–cleanup-post’ option which will address any leftover RHEL 6 packages once the system comes up and ‘–reboot’ to go ahead and automatically reboot the system when the prep is done. I’m going to ignore the optional channel for RHEL 7, but you can add an additional repo on the command line. You can find the set of options that best suits your needs.
# mount /dev/cdrom /mnt
# redhat-upgrade-tool --device /dev/cdrom --cleanup-post --reboot
Continue with the upgrade [Y/N]? y
getting boot images...
vmlinuz-redhat-upgrade-tool | 4.7 MB 00:00 ...
initramfs-redhat-upgrade-tool.img | 32 MB 00:00 ...
setting up update...
upgradedevice/filelists_db | 3.0 MB 00:00 ...
finding updates 100% [=========================================================]
testing upgrade transaction
rpm transaction 100% [=========================================================]
rpm install 100% [=============================================================]
setting up system for upgrade
Loaded plugins: product-id
redhat-upgrade-upgradedevice | 4.1 kB 00:00 ...
redhat-upgrade-upgradedevice/primary_db | 3.4 MB 00:00 ...
Broadcast message from firstname.lastname@example.org
(/dev/pts/0) at 11:52 ...
The system is going down for reboot NOW!
You can watch the console as your system boots into the update image and starts the magic. I didn’t find a way to capture the console output cleanly, so you’ll just have to imagine it. Essentially, the system boots into a RHEL 7 minimal system and runs the upgrade tools, then reboots.
Once the system comes back online, I can see it’s now a RHEL 7 box
# cat /etc/redhat-release
Red Hat Enterprise Linux Server release 7.0 (Maipo)
# systemctl get-default
I can go ahead and re-enable the RHN plugin for Satellite and refresh the repolist. If you look at the system profile in Satellite after you refresh the repolist that the base channel has updated as well. You’ll still want to sync the profile to fully update the record.
# vim /etc/yum/pluginconf.d/rhnplugin.conf
enabled = 1
gpgcheck = 1
Updating package profile...
Updating hardware profile...
# yum repolist
Loaded plugins: product-id, rhnplugin, subscription-manager
This system is not registered to Red Hat Subscription Management. You can use subscription-manager to register.
This system is receiving updates from RHN Classic or Red Hat Satellite.
file:///mnt/repodata/repomd.xml: [Errno 14] curl#37 - "Couldn't open file /mnt/repodata/repomd.xml"
Trying other mirror.
rhel-x86_64-server-7 | 1.5 kB 00:00
rhel-x86_64-server-7/group | 620 kB 00:00
rhel-x86_64-server-7/updateinfo | 108 kB 00:00
rhel-x86_64-server-7/primary | 4.4 MB 00:00
repo id repo name status
rhel-x86_64-server-7 Red Hat Enterprise Linux Server (v. 7 for 64-bit x86 4,991
You saw the upgrade process leaves behind the repo entry used during the upgrade, so I’ll remove it.
[root@localhost ~]# cat /etc/yum.repos.d/redhat-upgrade-upgradedevice.repo
name=Upgrade - upgradedevice
[root@localhost ~]# rm /etc/yum.repos.d/redhat-upgrade-upgradedevice.repo
rm: remove regular file ‘/etc/yum.repos.d/redhat-upgrade-upgradedevice.repo’? y
Last step is apply any updates for RHEL 7 I’ve got lurking around in the channel.
[root@localhost ~]# yum -y update
And there you have it. One fully upgraded RHEL 7 system from a RHEL 6 start. Pay attention to the tools and the caveats, even though I played a little fast and loose here. I’ve spent quite a bit of time profiling clean installs and still put in a few tickets with Red Hat. Take care to test and re-test before working on production systems.