Comparing live version upgrade methods
When I review a distribution I always begin by performing a fresh installation of the operating system. This gives the latest version of the project a chance to stand on its own without complications. However, many of us do not perform fresh installations on our operating systems each time we want to upgrade to the latest release. Some of us, in order to preserve settings or installed packages, prefer to upgrade our existing operating system without starting over from scratch. This week I decided to take five open source operating systems through an upgrade process from their penultimate release to their latest version.
During my series of experiments with Debian, Fedora, FreeBSD, openSUSE and Ubuntu, I focused on four important characteristics of the upgrade process:
- Is the upgrade process well documented and is that documentation easy to find?
- Is performing this upgrade process something that should be easy for new users to understand and perform? For example, can it be done through a GUI or by executing one program on the command line?
- Were there any complications, extra steps or errors to be worked around?
- Did the upgrade process ultimately work?
With each distribution, I installed the previous release, added a few packages and changed some settings. Then I updated all the packages installed on the system before following the distribution’s documentation to upgrade to the project’s latest version. Following the upgrade, I checked to see if my settings and package selection had survived the upgrade process.
I would like to acknowledge up front that this trial explores a risky approach to upgrading an operating system. Most modern systems provide two ways to upgrade an existing installation: off-line and live. The off-line approach involves downloading new installation media, taking the system off-line and running an upgrade process from the installation media. This is generally considered relatively safe, if a bit inconvenient since it means we need to take the computer off-line and download new installation media. This week I explored running live upgrades which means the system stays on-line and only downloads packages which are needed to perform the upgrade. This is a bit more risky, but means we don’t need to stop working on the system while the upgrade happens and we do not need to burn a new installation DVD. I am the type of person who wants to keep the system up and running during an upgrade, I want to keep working while packages are being updated in the background and that was what I was testing this week.
* * * * *
Ubuntu 15.10 to 16.04
I decided to begin my trial withUbuntu, starting with the Desktop edition of Ubuntu 15.10 and upgrading it to the latest long term support release, Ubuntu 16.04. The distribution’s release notes include basic instructions for upgrading the distribution across major versions. The instructions point out that while we can upgrade interim versions of Ubuntu (those which are not long term support releases) at any time, people who wish to jump from Ubuntu 14.04 LTS to 16.04 LTS need to wait a few months. The jump from 14.04 to 16.04 needs to wait until the distribution pushes out an update release, specifically version 16.04.1. This means people making the jump between long term support releases wait a few extra months, but gain additional stability and bug fixes when they do finally perform the upgrade.
There are detailed upgrade instructions in the Ubuntu wiki which provide us with a variety of ways to upgrade our version of the operating system. The wiki covers upgrading through the graphical user interface and via the command line. For some reason the wiki also covers an extra, unsupported "Debian way of upgrading" though it hardly seems necessary.
In practise, most people probably will not need to read any instructions in order to upgrade Ubuntu. When we launch the distribution’s graphical update manager, the application checks for package updates. If none are found, the update manager will check for new versions of the operating system and give us the option of upgrading to the new release. Clicking the button to start the upgrade shows us some release notes and, when we confirm we wish to continue, the update manager downloads the new release. We are shown progress information while the new packages are downloaded and installed and our configuration is updated.
The upgrade process on Ubuntu is pleasantly easy, requiring just a few mouse clicks and it uses the same update manager people are likely running every week to obtain security updates. In my trial, the whole upgrade process took about three hours and I was able to use the distribution while the update manager was working. All that was required on my part was a couple of mouse clicks and to reboot the computer when the update manager had finished its work.
Following the reboot, Ubuntu 16.04 ran smoothly, my settings were maintained and everything worked as expected. From a technical point of view, I would give Ubuntu five stars out of five for a quick and easy upgrade process. The wiki could be streamlined a little, removing unsupported upgrade methods, but otherwise everything went beautifully.
* * * * *
Fedora 22 to 23
The next distribution on my list wasFedora and I decided to upgrade Fedora 22 Workstation to version 23. (Fedora 24 will be released shortly after this article is published, but the upgrade process between versions does not appear to be changing for the upcoming release.) Fedora provides multiple methods for upgrading through the project’s wiki . Available upgrade methods include the recommended approach that uses a DNF package manager plugin and there is an alternative upgrade method which uses plain DNF. Yet another method that is talked about can be used on Fedora’s Atomic Host edition. I decided to stick with the recommended approach with DNF’s system-upgrade plugin.
I found Fedora’s documentation to be fairly straight forward. We do need to use the command line, but we can pretty much just copy and paste a few commands from the Fedora wiki into the GNOME desktop’s virtual terminal in order to perform the upgrade. The process involves us updating existing packages, rebooting, installing the DNF system-upgrade plugin, running the plugin and rebooting the computer. When we reboot, the upgrade process automatically installs the new packages during the boot process, before we get to a login screen. The system will then reboot itself automatically and, if all went well, we will be running the latest version of Fedora.
During my trial, the upgrade process (from installing the system-upgrade plugin to running my new copy of Fedora 23) took approximately four hours. The upgrade completed successfully and, though it required some command line work and two reboots, went smoothly. In the end, I was running Fedora 23, the system was stable and my settings survived the upgrade process.
In a way, I feel Fedora is cheating a little as we need to take the system off-line and boot into a special upgrade process that prevents us from using the computer during the final stage of the upgrade. This makes the Fedora upgrade a hybrid of off-line and live methods. Still, it worked and the off-line portion of the upgrade required relatively little time.
* * * * *
Debian 7 to 8 (Wheezy to Jessie)
You might want to add suggested packages or deselect packages which are only recommended and known not to be useful. In any case, the front-end should come up with a scenario ending in a coherent and up-to-date Jessie system.
" Which seems like a roundabout way of saying we may wish to remove any packages we do not need.
If the [repository configuration] file only contains references to Stable rather than explicit codenames [like Wheezy], the change isn’t even required, since Stable always refers to the latest released version of Debian.
" This gave me pause as I hope most people do not take this to mean they should use "Stable" in place of the current version of Debian. Doing so may cause problems when the next version of Debian is released.
I performed a vanilla installation of Debian, taking all the default packages and settings. Following the installation, I found APT’s repository files only included the update (security) repositories and I was unable to install additional software. I fixed this and then updated the system so I was running the latest packages in the Wheezy branch. Then I followed the documentation and tried to launch Synaptic. At this point I discovered the Synaptic graphical front-end for package management was not installed on my system. I decided to drop to the command line and use the apt command line utility to perform the instructions in the Administrator’s Handbook, only to find apt was not installed either. The documentation should probably mention installing these items is required before suggesting we use them.
In the end, I installed apt , updated my repository information, performed a minor upgrade, rebooted and then performed the full upgrade. Each step in the process went smoothly and, in total, the upgrade required about three hours. While my new Debian 8 installation worked well, I noted there were several big changes to the default desktop environment, GNOME. Debian releases generally happen about once every two years, resulting in a relatively long life cycle and this means applications tend to change a lot between Stable versions of Debian.
On the technical side of things, Debian requires a bit more know-how and manual work than Ubuntu or Fedora. However, in the end, I was able to upgrade Debian while continuing to use the system. My big issue with Debian is not with the technical aspects of the upgrade process, but rather the documentation. Perhaps it is just me, but I found the documentation to be vague, relatively hard to find (compared to the other projects in this trial) and the Handbook refers to running software not available following a default installation.
* * * * *
openSUSE 13.2 to 42.1 Leap
openSUSE was the last of the Linux distributions on my list of projects to upgrade. The documentation on the project’s website includes a section on upgrading across major versions , including openSUSE 13.2 to 42.1 "Leap". The openSUSE documentation was definitely the most complex of the projects included in this trial. Not only does openSUSE require people performing live upgrades use the command line, but the documentation suggests using long sed commands and switching init runlevels, something none of the other projects required. In all, there are about four pages of documentation to read through and we are walked through switching repositories, changing runlevels, removing and then re-adding community repositories.
The first problem I ran into was updating openSUSE 13.2 as the graphical update manager refused to work. I traced this problem back to PackageKit, which would lock the package database and refuse to terminate. With the PackageKit process manually terminated, I updated my openSUSE 13.2 system and rebooted. Then I updated my repository information, imported the new 42.1 Leap security keys, refreshed my repositories and began the upgrade. The zypper command line package manager immediately ran into package conflicts and entered an endless loop where it would ask (over and over) if I wanted to skip, retry or cancel the current operation. After dozens of these repeated prompts, I aborted the upgrade.
Earlier I mentioned that I did some customization to each operating system prior to performing an upgrade in order to see if my changes would survive a live upgrade. In an effort to be fair, I attempted an upgrade of openSUSE using only the default settings. My installation was performed from the recommended full DVD, no third-party or community repositories were added and no additional software or configuration changes were made to the system. The upgrade still failed immediately following the zypper upgrade command.
openSUSE stood out in my trial as the only operating system to fail to upgrade successfully. The distribution also stood out as having some of the most complex documentation.
* * * * *
FreeBSD 9 to 10
) which run on FreeBSD are updated constantly, and separately. This means, during the supported life of a FreeBSD release, we mostly just update the packages which run on the operating system while the core remains static. When we upgrade the base system, we are upgrading a small core of software without the need to alter the programs which run on top of the core as they are already up to date.
FreeBSD Handbook . One multi-page section deals specifically with upgrading the core operating system across major versions. There are several steps listed in the Handbook, but they are generally straight forward. One of the few problems I spotted was that we need to provide the command line update manager with the name of the release to which we are upgrading. The name, in this case, is usually the version number of the new release, followed by "-RELEASE". For example, upgrading from FreeBSD 9.3 to version 10.0 requires we run "freebsd-update -r 10.0-RELEASE upgrade".
In total, there are four commands we need to run in order to upgrade FreeBSD across versions, five commands if we include a final reboot to make sure everything is in place and working correctly. The commands are listed in the project’s Handbook and I found the upgrade process happens just as it is documented. As we just need to upgrade the core of the operating system, the process is fairly quick, taking around ten minutes in my trial.
I ran into just one quirk during the FreeBSD upgrade process that gave me pause and made me think upgrading FreeBSD would not go smoothly with less experienced users. During the initial stage of the upgrade process, FreeBSD downloads a new version of the operating system and then compares the configuration files we currently have in place against the new versions of the configuration files. When any difference is discovered, we are asked to manually edit a mash-up of the two files, removing the unwanted pieces and saving the pieces of the configuration we wish to keep.
Performing this comparison of combined configuration files and deleting the unwanted parts was not a fun experience and I have performed upgrades of FreeBSD multiple times in the past. The process is messy, not particularly clear on why things are changing across versions and it is easy to miss symbols the FreeBSD upgrade process introduces which can cause errors when the system boots. To make matters worse, if we spot an error and want to go back to fix it, we need to abort the upgrade and start over. The upgrade process is not long, but it’s not the sort of thing one wants to repeat due to hitting one wrong key.
In the end, my upgrade of FreeBSD was successful and did not take long. The process is well documented, but requires a good deal of manual work from the command line. It is one of those tasks that an experienced FreeBSD admin can probably zip through in five to ten minutes, but newcomers are going to see the multiple command line steps (plus the manual editing of configuration files) and probably decide it will be easier to perform a fresh installation.
Operating systems are, at the end of the day, tools for us to use. Different tools tend to be used to perform different tasks and are designed differently. I mention this because while the Ubuntu Desktop upgrade process involves a few mouse clicks and very little effort (making it quite appealing), Ubuntu’s method would not suit someone running a Debian or FreeBSD server. Those operating systems are intended for different environments and so none of the projects mentioned in this trial lend themselves to direct "apples-to-apples" comparisons.
That being said, each project had very different approaches to achieving (approximately) the same task. As mentioned above, with Ubuntu the user doesn’t even need documentation. The usual update manager will simply tell the user a new version is available and perform the upgrade with virtually no action required from the user, other than to confirm the upgrade should happen. This approach was welcome and it worked very well.
Fedora’s approach was relatively easy and well documented. While some command line work was involved, I suspect anyone who can set up Fedora Workstation to begin with will probably find performing a live upgrade fairly straight forward. I think the same can be said for FreeBSD. The FreeBSD upgrade process is well documented and involves about the same number of steps as Fedora’s process. Where FreeBSD really shines is the time required. While the fastest Linux upgrades took about three hours, FreeBSD only needs to upgrade the core of the operating system and this can be accomplished in about ten minutes.
For me, the Debian and openSUSE upgrades were a bit disappointing. Debian mostly due to the documentation, though the manual editing of all the APT .list
files added a cumbersome step to the process. However, I will say Debian’s upgrade process did work and went relatively quickly. The openSUSE upgrade was troublesome from start to finish with long, complex documentation, a misbehaving PackageKit process and, in the end, the upgrade failed.