Chasing a Xenial
A log from an adventure
On 08/08/2016 I found an article about LTS support dates of Ubuntu. You know I’m lazy, I use Ubuntu in a few of my web pages (calling work). I went to check the Releases page, and I was confused. What is the meaning of the HWE August 2016 in Ubuntu 14.04.4 LTS line? I’m out of time, and a least one of my server is EOL?
Forget about a fact for a second I just misread my `lsb_release -a` command. Wich is said ”Ubuntu 14.04.5 LTS”.
So, I decided to test and upgrade to the new shiny-winy Xenial. Which is available from only a day earlier, and my MOTD kindly reminded me.
New release ’16.04.1 LTS’ available.
Run ‘do-release-upgrade’ to upgrade to it.
I have a virtual environment on my computer for testing and developing. Which is a Vagrant machine, powered by VirtualBox (very poorly if you want to develop web pages which are the whole point. I’m looking at you sendfile).
Moving on
Fired up my terminal, promptly typed `v box add ubuntu/xenial64` modified my `Vagrantfile` and waited. Eeeeek. Doesn’t seem to work. Ok, let google it -> turns out there is a bug #1. Ok, so I could not test my application easily. No worries, I can upgrade to Xenial anytime, a little time-consuming compared to a simple download of a new image, but doable.
Let’s try.
I just opened my Trusty and started the upgrade. But no so harsh, let’s test the upgrade process first:
`sudo do-release-upgrade -s`
Sandbox setup failed
It was not possible to create the sandbox environment.
Preparing the upgrade failed
What?
It turns out there is no `aufs` support in `ubuntu/trusty64` Vagrant box. A quick search (again) there is a solution. Did I mention I’m lazy? I just copied the whole `sudo apt-get install aufs-tools linux-image-extra-virtual` line, restarted my box and started again: `sudo do-release-upgrade -s`. Now, the whole process seems to work.
Intermezzo
- Along with the road of the update process, there is a warning about `ssh` connection. I decided to ignore it. On my machine, I can fire up the VirtualBox, and access my Vagrant box console. But the reality of any VPS update that you have to use ssh to access. So let’s see there is any problem (turns out at the end, there is no problem, I already using Xenial supported chipper in my ssh config).
- From the nowhere, the phpMyAdmin asked me what is the hostname of the MySQL server. I don’t remember this type of question when any time I install a phpMyAdmin on a box wich has a MySQL server on it. The config script just doesn’t search for local MySQL instances anymore? Who knows?
- And there was a second question about chef’s server URL too. Did I have chef? What was it? Google it again, and now I remember. It is a Vagrant supported provision method (from my point of view), so it is logical to installed already. I decided to ignore the question and left the server field empty.
Back to track
On the end of the upgrade script, another error waits for me.
Errors were encountered while processing:
grub-pc
Another bug? Yes, it is. A bug #2. OK, I sandboxed an update for a test reason, in a test environment. Did I seems too cautious? Maybe. Let’s carry on. I can always recreate my box if anything goes wrong.
Another intermezzo
Let’s face it. Release upgrade is a time, disk and memory consuming process. But I not expected to fail because of low memory. My Vagrant box has allocated 1024 MB, `v.memory = 1024` in my Vagrantfile, but it is simply not enough. This is odd. I checked the requirements before starting. So increase to 2048 MB and start again.
Are we there yet?
So the upgrade is completed, you should not restart the box, obviously this is a very nature of sandboxing. Eventually, can I start testing my app? Please?
Nope.
The shared folders just stop working. My app is not on my machine anymore. Bummer. Makes sense to need a restart to the new VirtualBox addition to work, but still.
So I could not test with this. Let’s try again the upgrade for real. Just `vagrant destroy -f && vagrant up && vagrant ssh` and a couple of minutes later‚ I can start the upgrade process. Again.
`sudo do-release-upgrade`
After a while, I had a freshly updated Xenial on my box. Restart. It was not booted. What happened? You guess. Another bug #3…
This is the end…
After a couple of hours of wasting time (a whole day actually) in my current environment, I couldn’t test my app in Xenial. I never upgrade any of my servers without testing, so no luck to actually enjoying the speed of PHP 7 and HTTP/2 altogether right now. It is simply not reliably available on Trusty (this is not a complaint). So I desperately waiting for 11/8/2016 (which is today) to test a freshly released cloud-images y-2016–08–11 “y-2016–08–11”
Now I have a launchctl script, which tries in every hour `vagrant box outdated`.