I was so excited to see RHEL 9.0 released out of beta stages and into GA (general availability) that I felt compelled to upgrade my RHEL 8 installation. Upgrading an existing installation to a newer version without going through a clean install is what Red Hat calls "in-place upgrade". Remembering how I was forced to do a clean install when upgrading from RHEL 7 to 8, I was intrigued by the process described in the RH docs on in-place upgrading.
All commands are executed as a user with elevated privileges, even the reboot.
Prerequisites:
- Get your existing RHEL installation to version 8.6
- Install the Leapp utility
- Uninstall apps with non-Red-Hat-signed GPG keys. These apps were reported by the pre-installation check utility to be able to crash the entire upgrade process.
- Run the pre-installation check to see what would impede or halt the in-place upgrade process.
Only after you satisfy all four can you assume safe upgrade to RHEL 9.
1. Get your existing RHEL installation to 8.6
I had my own installation at RHEL version 8.5 so I needed to update to 8.6. There was actually a lot to update. Make sure your BaseOS and AppStream repositories are enabled. They are on most RHEL 8 systems unless you heavily customized your own system since the original RHEL 8 installation.
dnf update
It will take A BIT of time. And once done with the update to 8.6, if you want to verify you are actually at 8.6:
cat /etc/redhat-release
or
subscription-manager list --installed
which should report RHEL 8.6 as the version you are running on. Next to do:
reboot
2. Installing the Leapp utility:
Yes, that's Leapp with "pp" at the end. Installing this utility is a prerequisite for carrying on the in-place upgrade:
dnf install leapp-upgrade
From here, you could stay with the command-line and run the pre-upgrade leapp to see if anything impedes the upgrade process- sort of a dry run, very helpful, I don't remember seeing this approach with the leap from RHEL 7 to 8. Or you could install Leapp's Cockpit add-on and carry on with running the pre-upgrade within Cockpit's terminal. The advantage of using Cockpit is that the report of pre-upgrade run will be presented graphically and you will have the option to take the required corrective steps with just a click of a button...
3. ...of course I went for the easy option and installed the Cockpit add-on:
dnf install cockpit-leapp
Log in to the web console by pointing your browser to https://localhost:9090, provided you have Cockpit up and running and listening to port 9090. Open the Terminal tab...
4. ... and then, in that terminal, run the pre-upgrade test:
leapp preupgrade --target 9.0
Test will take SOME time to complete, after which you'll be presented with a report both on the terminal and more importantly, as an option at the bottom of the left bar of Cockpit's page. Click on the Upgrade Report to view and take action on possible future complications on your upgrade path.
Color coding is done right. In both CLI version of the report and the graphical version, red means trouble. Potential problems are graded with a Risk Factor on different levels, in which High can rarely be ignored. Problems are also graded as Inhibitor yes/no. An issue can have a risk factor of High and an Inhibitor- which issue can definitely not be ignored but just follow the corrective steps suggested.
In my case, Google Chrome and VS Code were highlighted as Risk Factor: High and Inhibitors because their RPMs' GPG keys aren't signed by Red Hat. I had to uninstall both to have the report come back with issues with low level risk factor.
Prerequisites satisfied? Upgrade!
Once you get that Upgrade Report to report issues in all blue (or green in CLI), you are ready for the upgrade!
leapp upgrade --target 9.0
and for the next hour (more or less, depending on the size of the filesystem(s) you're upgrading and the speed of your internet connection) the process is pretty much automated.
Conclusion
The whole process, from updating to RHEL 8.6 to upgrading to RHEL 9 and getting back the fully upgraded system back for my usage took 3 hours. It isn't a trivial undertaking compared with upgrades on more consumer-oriented OSes, but it's much, much better compared with the upgrade from RHEL 7 to 8.
Top comments (0)