Upgrade Ubuntu 14.04 LTS to an higher version on Gandi Cloud servers¶
Ubuntu releases cycles¶
LTS versions (long-term Support) of Ubuntu distribution are intended for use on production servers. They are stable, and long-term updates are available for 5 years. These LTS versions are released every 2 years.
It is important to do these updates and upgrades, as a server should never be left without update support, mainly for security reasons. It is highly reccommended that you update to the most recent version, especially if the version you are using is no longer supported.
You can find more information on the releases cycles of Ubuntu LTS on this website : https://wiki.ubuntu.com/LTS
Before upgrading¶
Upgrading is not complex, but there is still a risk the update may break the proper running of some libraries and software packages used by your applications. When you upgrade to a higher version, there is also always the risk that a configuration file or a language is incompatible with the new version.
The virtualization provided by Gandi Cloud allow us to proceed step by step, by systematically validating the proper functioning of each application. This tutorial will cover a general case as it is impossible to detail the update of all possible services and configurations. We will show you the best practices to follow for a mastered upgrade, using Gandi Cloud Services.
Verify the Current Version of Your Server¶
To verify the current version used by your server, you just need to run the following command:
roo@server:# lsb_release -a
If the current version is less or equal to 14.04, we highly recommend upgrading, but in all cases you should do the upgrade if the current version is less than 18.04.
Note that upgrading a server with multiple services installed is not necessarily the best solution. It may sometimes be better to create a new server with a more recent version of the OS, and reconfigure the different services directly in this new version. You can then detach and attach your volumes to move the data from the old server to the new one.
Prerequisites¶
Before starting the upgrade of your server(s), we recommend listing all the different software packages and applications running on the server, and their dependencies. This can be a language version, some software, or a specific library.
You can start by verifying the current version of packages provided by the distribution using this website: https://packages.ubuntu.com/en/
We also recommend that you use the snapshot functionality to create an image file of your system disk before applying any changes. Snapshot will allow you to create a new server based on the current one. You can then complete and test the upgrade on this duplicate server before upgrading your production server.
Note
The new server you create must be in the same datacenter as the old server to be able to use the snapshot.
Please note that this new server will have a new IP address, and that you will have to duplicate all the other disks (if any) and attach them to the new server. When upgrading is finished, you will then detach the IP address from the “old” server and attach it to the new one, then make any updates necessary to make the IP address fully functional.
Upgrading¶
After creating the new server from the snapshot, log in as root so you will be able to do administration tasks. Canonical recommends the use of the command do-release-upgrade to make this upgrade. By using this specific command, the system will search the next LTS version of Ubuntu based on your current one. So, if your current version is 14.04, it will upgrade your system to 16.04.
You can verify which version you are upgrading to using the command do-release-upgrade -c. Then to start the upgrade, run the command:
root@server:#do-release-upgrade
When all the updates and upgrades have been done, you can verify that all of your services are working properly. You can edit the hosts file to redirect the domain generally used to the new server IP address. This will let you locally test the “new” server without having to change the DNS records of the domain used in production. Make sure to return the hosts file to its original state after your testing is complete.
Going Into Production¶
If the upgrade didn’t encounter any errors and all the services are nominal, you can then use the server in production. To do this, reassign the network interface from the old server to the new one, then start. Before proceeding to detach and attach the interface, you should first modify the files below:
/etc/default/gandi: remove the value of eth0 and NO_DHCP so the files looks like this:
NO_DHCP=""
/etc/network/interfaces: replace the network configuration for eth0 with the following:
auto eth0
iface eth0 inet dhcp
These changes are necessary so that the IP address we attach will be used during the next start of the server. You can now stop the old and new servers, and detach the network interfaces of both.
Then, attach the interface from the “old” server to the new one and start it. All services should be nominal on the new server.
Troubleshooting¶
If the server does not respond after you restart, you can activate the emergency console and log in via SSH and verify the origin of the issue.
If the server will not start, you can set the kernel to “ramdisk-rescue”, which will load a Linux system in RAM. When started, you can mount the system disk and do a chroot on it.
First, mount the system disk in a directory.
# mkdir /mnt/chroot
# mount /dev/xvda1 /mnt/chroot
Then, mount the pseudos filesystems.
# mount -t sysfs /sys /mnt/chroot/sys
# mount --bind /dev /mnt/chroot/dev
# mount -t proc /proc /mnt/chroot/proc
Then we switch to chroot, via command chroot /mnt/chroot. Commands run in chroot will be used the same as if you had started the server normally.