My home server runs on Ubuntu Server. So far that was the 14.04 LTS (‘Trusty Tahr’) version. But since Canonical has made available the first point release of the newer 16.04 LTS (‘Xenial Xerus’) version, i.e. version 16.04.1, upgrading became an option. Ubuntu actually makes this simple for users – but be forewarned, there are pitfalls and glitches! I managed to upgrade smoothly, however with one serious hick-up. So, whether I will also upgrade the Ubuntu version on my VPS, I have not decided yet.
Upgrading and its precautions
Some precautions to start with:
- First, do not blindly jump into upgrading. If your server really must not have any downtime, first test the upgrade with all of your applications, e.g. on a virtual machine.
- Second: Backup Or Die. Be sure you cannot lose any files you cannot miss.
- Third: do not try this using a SSH connection. It might very well work, but you may just as well end up in deep trouble. Direct access to your server is the safest method.
- Forth: before you start the upgrade make sure your 14.04 LTS system is fully up-to-date by running sudo apt-get update && apt-get dist-upgrade.
- And last but not least: make sure you have the correct Ubuntu Installation Guide close at hand. You might even read it…
Having said that, upgrading can be pretty easy. Ubuntu recommends to upgrade using the do-release-upgrade command. So, log in to your server and type:
sudo do-release-upgrade
Keep an eye on your screen, since you will be asked a question every now and then. Once the procedure is completed you will be asked to reboot the system. Here is some more information about the process (which may be slightly different depending on what you have installed on your server). And that’s it.
The hick-up
I mean: that should be it. But when I rebooted my server, I got a number of error messages, the most important one being that my file system could only be mounted as read-only. Which basically means you cannot do anything on your system.
But I was lucky. The GRUB menu at system start offered the option to start from another kernel image, one including Upstart, the new replacement for the SysV-style init daemon. That gave me access, so I could spot the problem and solve it.
To check what was wrong with my file system I ran:
sudo fsck -Af -M
That returned this error message:
Unable to resolve 'UUID=fc7ee86e-7594-461f-952d-d8dfa8c7c119'
Then I ran this command:
sudo blkid
Which returned this information:
/dev/sda1: LABEL="roet" UUID="41341ac9-08f8-4d71-8023-cae16b1082aa" TYPE="ext4" PARTUUID="000cad40-01"
/dev/sda2: UUID="637da82b-f5f3-4755-bbad-5b565c30cdc0" TYPE="swap" PARTUUID="000cad40-02"
/dev/sda3: LABEL="sjer" UUID="eee62246-04ed-4520-a60f-3a3130bb5333" TYPE="ext4" PARTUUID="000cad40-03"
Then I checked what fstab was actually trying to mount, and it turned out that for some silly reason the root partition had a wrong UUID assigned to it. I replaced it with the correct UUID that blkid gave me, saved fstab, rebooted, et voila! everything worked fine.