I had a moment of foolish optimism and decided to upgrade my development machine from Ubuntu 14 (Trusty) to Ubuntu 16 (Xenial). “Just run do-release-upgrade”, the motd has been encouraging me for months now. So I did.
And it failed. And then I tried to fix it by hand and I thought I did. And then the machine didn’t reboot. So that’s discouraging. But then the second time I tried to reboot (after hauling the machine over to a monitor) it rebooted fine. And now the machine is fine. No idea what that was about, but yay for Ubuntu robustness! My reboot problem may have nothing to do with Ubuntu, but rather be a problem with my ethernet. Anyway, some notes.
On the upgrade scripts
- do-release-upgrade runs in a screen session. Some of the upgrades prompt you to compare changes in config files, and will helpfully propose spawning a shell to let you inspect the situation. But your tty is occupied in some weird way with screen and/or scripts running in the background. I was getting all sorts of random crap on my screen and I panicked and aborted the upgrade script. Do not make this mistake.
- You can’t run do-release-upgrade a second time. The system thinks it was already upgraded and it aborts.
- Fortunately mostly do-release-upgrade does stuff up front, then relies on apt and dpkg to do the real work. Those tools are robust. I’m not really clear on what all do-release-upgrade does, but here’s a reference. I sure hope there wasn’t anything crucial that didn’t happen because I aborted.
- I fixed things by running dpkg-configure by hand, then running apt-get upgrade a bunch of times. apt-get dist-upgrade is probably not a bad idea either.
- I also improved things by removing a bunch of PPAs from /etc/apt/sources.list.d.
- There are some install logs in /var/log/dist-upgrade, including a full screen recording.
On changes in Ubuntu 16
- Welcome to systemd! Everything about how the machine boots is different. I mostly noticed this with warning messages printed at boot time about funky scripts in /etc/rc that weren’t up to snuff. These came from me or PPAs, not the core code.
- “systemctl” seems like an important new command to learn. Useful commands: enable/disable, start/stop, status. Also “journalctl” to see systemd’s logs.
- some init scripts were broken / old / weird. I have a bunch of old cruft! I fixed these by purging the packages and reinstalling them. Culprits included screen and mongodb.
- My 2012 lm-sensors install included some kernel modules that no longer exist. Fixed by re-running detect-sensors and removing the old entries from /etc/modules
- I’m getting an error about mount options in dmesg that I can’t understand. It doesn’t seem to be hurting anything though, so ignoring it.
- grep thinks my syslog is a binary file, it has some nulls in it (which is terrifying!). So i have to use “grep -a” to see the whole thing.
On user programs
- I run Crashplan which makes extensive use of inotify. The default Linux settings only allow 8192 files/directories to be watched, not enough. Here’s how to update the limit.
- I had to manually install python3-venv with apt. Then my existing venv directories were broken and I had to rebuild them.
- My plex server was broken. Difficulty level: systemd. I finally traced the problem down with help from here; “systemctl status” told me it was having a problem with the group. Turns out the server wants to run as group plex, not just user plex, but no one had set up a group plex. BTW hooray! The Plex team finally has an official apt repository
- I somehow ended up with Postgres 9.1, 9.3, and 9.5 all on my system. With 9.3 and 9.5 daemons fully running. I don’t have any permanent data on the development machine so I went with a full wipe and reinstall of all Postgres. The stock Ubuntu 16 versions of GDAL and PostGIS seem to work nicely.