Updated: November 19, 2018
The Plasma desktop environment household demonstrator is KDE neon, a distro that prefers not to be known as a distro, based on Ubuntu and loaded with Plasma. Until recently, the system used Ubuntu 16.04 LTS as its foundation, but now, a new version has been released, with 18.04 running through its veins.
We've already sampled of this fine beast a few days ago, when I showcased Plasma 5.14. I told you I'd continue the testing with my installed version of neon, and here we are. This distro sits in an eight-boot setup on my Lenovo G50 machine. Now, I shall attempt to upgrade, and the results shall flow like treacle? Or blood? You choose.
The command wossname thingie
According to me sources, you can upgrade neon using Discover. I went for the good ole command line way, running a single one-liner, which is also applicable for all flavors of Ubuntu, btw. I did use it for Kubuntu upgrades quite a few times. No big issues.
Resilient, it is
I let the system run ... but then decided I needed to actually pause the upgrade. This is NOT recommended, and the text wizard warns you against this. But yolo. So I suspended the box first. The system warned me that it was trying to inhibit my command, and I had to provide my password to actually complete this step.A few hours later, I woke the machine, and it continued running just fine. But I needed another pause, only this time, the system would not sleep. It ignored my attempt. Double yolo. So I actually hard-powered the machine, expecting the neon instance to be busted nicely and thoroughly.
It did boot with errors, but it wasn't completely broken. I had no network, but I was able to resume the upgrade by running the dpkg-reconfigure command, which picks up interrupted package installations and tries to complete them all nice and proper like.
sudo dpkg-reconfigure -a
About an hour later, the command finished. Reboot.
And we're back in the game
Quite remarkably, KDE neon started the second time around without any issues. The upgrade process had completed, successfully, despite my (dangerous) insistence to interrupt it - twice - once with a hard shutdown. This is never advisable, but it's also a good indicator of how robust the system is, and I have to say, I'm quite impressed.
Things were working fine. Nothing was missing. No weird errors. The only thing that's tricky is actually figuring out what version of neon you're running. The about page gives you all sorts of techie details, but nothing simple and conclusive. I checked against the configured repo sources, and this gave me the info I needed:
deb http://security.ubuntu.com/ubuntu bionic-security main restricted
# deb-src http://security.ubuntu.com/ubuntu xenial-security main restricted
Anyway, lovely jubbly. Fast, slick, elegant. Nothing crashed. The performance is superb. This KDE neon also runs the stable dev version, so it's supposedly more prone to going wonky, and there were updates on top of my upgrade within less than one hour of testing. Surprisingly, there were no hiccups. The remarkable resilience is almost too good to be true. Fingers crossed.
I also checked the battery life performance under quite moderate to heavy workloads, including lots of music and video streaming, browsing and whatnot, with full display brightness. With the battery cell down to about 80% of its full capacity, and roughly an hour of testing, I ended up with about 70 minutes of spare battery life. This translates into about 2-2.5 hours of heavy activity, maybe 3 hours with brightness down to 50%, so we're talking a comfy 4 hours perhaps for light usage. Top that with 20-25% battery degradation compensation. Very neat.
One interesting snippet of information is a part of the upgrade log, during the GRUB configuration rebuild, which happens a few times throughout. There was a message about the no-matching swap device being found, and the system falling back to what was specified in the /etc/fstab file.
W: but no matching swap device is available.
I: The initramfs will attempt to resume from /dev/sda10
I: Set the RESUME variable to override this.
Which is good! Because this is exactly the kind of error that caused my problems with the slow boot on the upgraded Kubuntu machine. I think I've figured out what the issue here is. Ubuntu uses the UUID notation for partitions in /etc/fstab, which should help you always find the right device, even if you have multiple disks and you change their boot order. But if you install other distros in the system - like I did with Xubuntu Cosmic, then you end up with a swap partition that gets re-formatted and its UUID reset.
KDE neon - and other distros - aren't aware of this, so when they remap the devices during the upgrade process, they will see a discrepancy between what the system expects and what's actually on the disk, and then you end up with the 90-second delay. This needs to be fixed in a more elegant way, in general. I like what neon did this here, and many newer distros use swap files (which simplify things), but a deeper, more precise partition auto-discover and change logic is definitely required here.
I am quite happy with the KDE neon upgrade, going from the 16.04 to the 18.04 base. I think it's good on several levels, including improved hardware support and even slightly better performance. Plus there were no crashes or regressions of any kind, always a bonus. This means that neon users now have a fresh span of time to enjoy their non-distro distro, even though it's not really committing to any hard dates, so the LTS is also only sort of LTS in that sense. It's quite metaphysical.
On a slightly more serious note, this upgrade was a good, positive experience. I semi-accidentally tried to ruin it, but the system recovered remarkably, the post-upgrade results are all sweet, and you have a beautiful, fast Plasma desktop, replete with applications and dope looks and whatnot. I'm happy, and we shall bottle that emotion for when the need arises, and in the Linux world it does happen often, I shall have an elixir of rejuvenation to sip upon. KDE neon, a surprisingly refined non-distro distro.