Nightmares from upgrading Ubuntu 14.04 to 16.04 LTS | Nathaniel Read

Nightmares from upgrading Ubuntu 14.04 to 16.04 LTS

This week in my half term; I decided that it would be a good idea to update my home server (an Intel NUC) from Ubuntu 14.04 to 16.04 LTS but the update wasn’t as straightforward as I had hoped (it never is!)

To update I thought I’d use SSH, but after receiving warnings in the terminal that if the session dropped it would cancel my update I decided to use RDP (through xRDP) instead. This started off great and the update was running well, until my session dropped and was lost by the RDP server (I couldn’t find it in the logs to reconnect to). I then was unable to get back in and SSH connected after a good 20 minutes of waiting. It seemed that the update had halted but DPKG was still locked, this command sudo rm /var/lib/apt/lists/lock removed the lock (thanks AskUbuntu). I attempted to resume the install using sudo apt-dist upgrade which I had used previously but was told I was already up to date on 16.04.

After another few questions on StackOverflow I found apt-get update,apt-get -f install,apt full-upgrade should return me to a working system, in total they took about a day to run, but eventually got going again.

The first thing that wasn’t working when I got back in were my network services which had all stopped, I got Apache, Plex, and the others running again before noticing that my NAS drive mounting had failed with mount.nfs: an incorrect mount option was specified, it was previously: /home/serviceusr/Desktop/photos nfs ,username=serviceusr,password=passwordhere,_netdev,rw,hard,intr,nolock

but after following some tips I got it working again using: /home/serviceusr/Desktop/photos sec=sys,intr,rw,vers=3,timeo=11,auto,async,bg 0 0

Docker also didn’t work after updating, I had to re-add its repository (disabled in the update) and install it again, the best guide for this is here. Previously I had run all my containers by using --restart=always on a container but this didn’t survive the update, instead I added them into my /etc/rc.local file for the future, like this:

docker run -p 8443:8443 -p 8080:8080 -p 8081:8081 -v /var/unifi:/var/lib/unifi  -d jacobalberty/unifi:latest

I also decided that I wanted a better backup system, as Syncthing on my Synology just wasn’t cutting it (running out of memory and restarting and stopping every 15 minutes) so I mounted the folder containing the users home folders with fstab on my server and then ran:

curl -s | sudo apt-key add -
sudo echo "deb syncthing release" | sudo tee /etc/apt/sources.list.d/syncthing.list
sudo apt-get install syncthing

Then had to run these, replace user with the account you want on the server:

sudo systemctl enable syncthing@$USER.service 
sudo systemctl start syncthing@$USER.service

This failed for me, and it took me ages to work it out with some vague errors, turned out I didn’t own the directory or executable, so run:

sudo chmod 777 -R /usr/bin/syncthing
sudo chmod 777 -R /home/USER/.config/syncthing/

The web interface should then be available on server:8484, the SSL certificates should be changed (if you don’t like security errors), they are /home/USER/.config/syncthing/https-cert.pem and home/USER/.config/syncthing/https-key.pem, I just symlinked them to my apache directory (easier to change my wildcard when it expires that way).

And that’s me up to present, hopefully this helped you if you received the same errors!