Today I decided to go ahead and upgrade one of my servers from Ubuntu 14.04 to 16.04. It is not recommended to do this on a production server, as there are many issues that can go wrong. Best practices always indicate that spinning up another server either as a replacement, or a temporary server is the safest way to go. That said, who doesn’t enjoy trying things that shouldn’t be done.
The upgrade went rather well, with one glaring exception, libvirt-bin was unable to be properly upgraded. Here are the steps to fix the situation as well as the steps that won’t.
Initial trial was to fix the problem with sudo dpkg –configure -a, no luck there. I also attempted using the aptitude auto resolver, then purging and reinstalling. Also no luck.
To get to the root of the problem, instead of foolishly trying to guess I ran
sudo journalctl -xe
As shown above a bug in apparmor, caused libvirt-bin to no longer have permission to run, as it was no longer configured (funny I could have sworn I told it to).
Here is how to fix the problem, and the root of the problem. First we need to purge the apparmor parser cache, since it has the data stored making libvirt-bin unable to start.
sudo apparmor_parser –purge-cache
Next we remove the rule preventing libvirt-bin from starting.
Then we go ahead and replace it.
Finally, we get to tell libvirt to restart, and all will be good.
sudo systemctl restart libvirt-bin
To check the status of libvirt-bin enter the following command
sudo service libvirt-bin status
This will output a nice little stat check of libvirt-bin, showing that the process outlined above did the trick. Now we can run our virtual machines again!
The other errors I am currently investigating, post upgrade, as well as solutions that can be implemented:
Failed to start LSB: exim Mail Transport Agent. This was a postfix error, resolved before machine was fully booted.
snd_hda_intel 0000:00:1f.3: failed to add i915_bpo component master (-19). This is a sound card error, can be corrected by upgrading Alsa (I don’t plan to use sound off the server, so this does not effect performance).
Lastly dev-disk-by\x2duuid-E7A1\x2dCC4A.device: Dev dev-disk-by\x2duuid-E7A1\x2dCC4A.device appeared twice with different sysfs. Apparently, the backup of my EFI partition was thorough enough to register it as the exact same UUID. The NVMe drive (primary) has a partition UUID, however the RAID (backup) does not .To rectify this I will leave the primary drive alone and change the UUID of the backup drive using uuidgen and then tune2fs /dev/sdx -U new-id-number-from-uuidgen.