Ubuntu server upgrade 16.04 to 18.04 (20.04 pending)

Virtualize, document, and test. The surest way to upgrade success.

For years my server has been running my personal websites and other services without a hitch. It was Ubuntu 16.04. More than four years old at this point. Only a year left on the 16.04 support schedule. Plus 20.04 is out. Time to move to the latest platform without rushing rather than make the transition with support ended or time running out.

With the above in mind I decided to upgrade my 16.04.6 server to 20.04 and get another five years of support on deck. I’m half way there, at 18.04.4, and hovering for the next little while before the bump up to 20.04. The pause is because of a behavior of do-release-upgrade that I learned about while planning and testing the upgrade.

It turns out that do-release-upgrade won’t actually run the upgrade until a version’s first point release is out. A switch, -d, must be used to override that. Right now 20.04 is just that, 20.04. Once it’s 20.04.1 the upgrade will run without the switch. Per “How to upgrade from Ubuntu 18.04 LTS to 20.04 LTS today” the switch, which is intended to enable upgrading to a development release, does the upgrade to 20.04 because it is released.

I’m interested to try out the VPN that is in 20.04, WireGuard, so may try the -d before 20.04.1 gets here. In the meantime let me tell you about the fun I had with the upgrade.

First, as you should always see in any story about upgrade, backup! I did, several different ways. Mostly as experiments to see if I want to change how I’m doing it, rsync. An optional feature of 20.04 that looks to make backup simpler and more comprehensive is ZFS. It’s newly integrated into Ubuntu and I want to try it for backups.

I got my backups then took the server offline to get a system image with Clonezilla. Then I used VBoxManage convertfromraw to turn the Clonezilla disk image into a VDI file. That gave me a clone of the server in VirtualBox to practice upgrading and work out any kinks.

The server runs several websites, a MySQL server for the websites and other things, an SSH server for remote access, NFS, phpmyadmin, DNS, and more. They are either accessed remotely or from a LAN client. Testing those functions required connecting a client to the server. VirtualBox made that a simple trick.

In the end my lab setup was two virtual machines, my cloned server and a client, on a virtual network. DHCP for the client was provided by the VirtualBox Internal Network, the server had a fixed ip on the same subnet as the VirtualBox Internal Network and the server provided DNS for the network.

I ran the 16.04 to 18.04 upgrade on the server numerous times taking snapshots to roll back as I made tweaks to the process to confirm each feature worked. Once I had a final process I did the upgrade on the virtual machine three times to see if I could find anything I might have missed or some clarification to make to the document. Success x3 with no changes to the document!

Finally I ran the upgrade on the production hardware. Went exactly as per the document which of course is a good thing. Uneventful but slower than doing it on the virtual machine, which was expected. The virtual machine host is at least five years newer than the server hardware and has an SSD too.

I’ll continue running on 18.04 for a while and monitor logs for things I might have missed. Once I’m convinced everything is good then I’ll either use -d to get to 20.04 or wait until 20.04.1 is out and do it then.

Windows 10 images

Windows’ various versions are the computer operating system I’ve supported my entire professional career. There have been very occasional instances of supporting other systems like Mac’s OS, both before and after Apple switched their OS to UNIX.

There’s many things I don’t like about Windows. I’ve stopped using it for my personal systems for around a decade now. One of many gripes is the installation and update process.

For a while I was fortunate enough to have a professional staff who developed Windows deployment images for our company. They were very good and made image deployment “just work”. It was to the point that about all that was necessary was network boot the pc, point it to the image source and sit back and wait.

I reviewed the procedures they created. Asked questions to better understand what needed to be done to create the Windows images. I never actually was hands on creating an image though. Not from my staff’s documentation and not with any of them shoulder surfing me through the process.

Years later I reached the point of needing to create zero touch deployment images on my own. I failed. It seemed I was close to the solution but never quite there.

Microsoft’s documentation is terribly frustrating for me for the task of image creation. I’ve not found a single Microsoft webpage that goes from zero to bootable deployment image. There’s lots and lots of webpages with instructions for various portions of the work. And some webpages with basic outlines that have links (too many) to details that themselves have many links to more details. Alice never went down such a deep rabbit hole.

Then I found Kari Finn`s guide to “Create media for automated unattended install of Windows 10” on tenforums.com. Kari takes all the diversions Microsoft provides and narrows them down into a single linear process that goes from having installation media to having a zero touch custom installation image. BRAVO and thank you Kari!

Using the guide I’ve finally made my first successful zero touch deployment image!!!

From here I’ll make custom images for the software installations and architectures, BIOS/MBR and UEFI/GPT, that I need to support.

Finally I can make my own images. The world is my oyster.