Before a do-release-upgrade in Ubuntu Linux, here’s a quick checklist of todo’s:
- Backup important files (apache sites / log files / conf files, PHP .ini files, databases, cron scripts, .bash_aliases, .profile, upstart scripts)
- Clear up enough space for upgrading (usually around 1GB)
- Open up a secondary SSH window and alternate port for firewall if you get disconnected a lot
- Change access to /var/run/screen to 777 (chmod 777 /var/run/screen)
- about 2-3 hours of time to upgrade (started 5:14pm, broken pipe around 7:35pm, restart 8:10pm)
The Linux server will continue to run while upgrade is downloading necessary packages.
First question will be: Disable SSH password authentication for root? If you’re using public/private key logins for SSH, go ahead and disable interactive typed password authentication for SSH. This is safer.
Second question: Restart services during package upgrade without asking? Sure. Unless you like to watch terminal windows for unknown lengths of time and clicking Yes over and over again.
Next the Linux server will download, unpack, and update packages, restart services as necessary, one-by-one until all Linux packages are at the latest version available.
You may be asked to replace some configuration files such as /etc/default/rcS. Since I have no recollection of changing that in paritcular, I’ll go with replacing it with the package maintainer (new) version. (The only change was to assume BIOS clock is set to time based on UTC). In other cases, such as jail.conf for fail2ban, I’d keep my own configuration file, since it’s full of my customizations to jails that I’d much prefer to keep.
For /boot/grub/menu.lst, I chose to “Install the Package Maintainer’s version” to replace my version with the new version. Nothing exploded. Or melted.
Recover from Broken Pipe during do-release-upgrade
During the ultra-long upgrade process you may get a Broken Pipe due to spotty Internet connection or accidentally closing your Terminal connection. At the beginning of the process do-release-upgrade noted an alternate SSH port where you can reconnect (usually port 1022). To reconnect to the active screen (here’s where the chmod 777 /var/run/screen comes in handy) first change the /var/run/screen permissions to 775 (chmod 775 /var/run/screen), then reconnect by executing the command screen -d -r. This will reconnect you to the running upgrade.