How to upgrade from 14.04 LTS

[Tom_ZeCat]

I see that 16.04 is LTS. I assume that means it's ultra stable. At one point I upgraded from 14.10 to 15.04 but was frustrated at the lack of stability. I therefore reverted to 14.04 LTS and have been happy. I did really like the redesign of 15.04; I just couldn't stand the bugs. Maybe it's time to give an upgrade another shot. I was pleased to see that 16.04 is LTS (http://www.kubuntu.org/getkubuntu/). I can always Clonezilla ghost image my drive in case I hate it.

I have in my Kubuntu notes database that you upgrade via the konsole as follows:

sudo apt-get update
sudo apt-get dist-upgrade
sudo do-release-upgrade -d

This will do it, right? My question is will it automatically set 16.04 to LTS? If I like this new version, I would prefer to stick with it when the next one comes out. I would rather go with the LTS versions rather than the very newest that might be buggy.

[oshunluvr]

IMO, I would do a clean install. There are numerous reports of buggy behavior from left-over bits affecting Plasma 5.

Also, 16.04 being an LTS release is not a reflection of "stability." Rather, it's an announcement of support. If you want stability, stay with 14.04 for a few more months at least. Let the bugs get worked out. I am going to install 16.04 today along side my 14.04, 15.04, and 15.10 installs in my usual manor.

BTW, by "stable" I assume you're using the English definition of stable, not the Linux one. In the Linux world "stable" means "no longer under development" not necessarily "unlikely to crash." I think "static" would have been a better term to have been adopted but no one asked me.

Also IMO; 16.04 is quite a ways away from "ultra stable" in both senses of the word. Good luck to you and I'll post my impressions later on as well, once I've used it for a bit. I usually have at least a weeks worth of adjustments to make before I can begin to use it daily.

[Tom_ZeCat]

IMO, I would do a clean install. There are numerous reports of buggy behavior from left-over bits affecting Plasma 5.

Also, 16.04 being an LTS release is not a reflection of "stability." Rather, it's an announcement of support. If you want stability, stay with 14.04 for a few more months at least. Let the bugs get worked out. I am going to install 16.04 today along side my 14.04, 15.04, and 15.10 installs in my usual manor.

BTW, by "stable" I assume you're using the English definition of stable, not the Linux one. In the Linux world "stable" means "no longer under development" not necessarily "unlikely to crash." I think "static" would have been a better term to have been adobted but no one asked me.

Also IMO; 16.04 is quite a ways away from "ultra stable" in both senses of the word. Good luck to you and I'll post my impressions later on as well, once I've used it for a bit. I usually have at least a weeks worth of adjustments to make before I can begin to use it daily.

Thanks for your advice. I'll stick with what I have for a while longer. Whenever I do upgrade, I'm definitely making a Clonezilla ghost image beforehand. That will give me a lifeline so that I can go back in case I hate it.

[bweinel]

If you want stability, stay with 14.04 for a few more months at least. Let the bugs get worked out. I am going to install 16.04 today along side my 14.04, 15.04, and 15.10 installs in my usual manor.

Yep... I agree with oshun. I'm sticking with 14.04 on my production machines until 16.04.1 comes out. By that time most of the remaining issues should be sorted. In the meantime, I'll probably spool up a test machine to play with 16.04...

cheers,
bill

[Teunis]

Providing you have some hard disk space to spare (~20-30GB) you can make two separate partitions and install 16.04 as an extra boot option.
I've been doing this for years, at the moment it's Windows, 14.04 and 16.04, the last is an upgrade from 15.10 and for an upgrade it's working surprisingly well.
If 16.04 keeps performing as well it is now I will in a few months replace 14.04 with 16.10, etc, etc.

You'd need a ~16GB root and some ~10GB for a /home.
As long as you shut down properly the swap can be shared.
Most of the content of the original /home (Documents, mail and browser) can be linked to it from your original home so the new /home will only need space for configuration files etc.

[oshunluvr]

Providing you have some hard disk space to spare (~20-30GB) you can make two separate partitions and install 16.04 as an extra boot option.
I've been doing this for years, at the moment it's Windows, 14.04 and 16.04, the last is an upgrade from 15.10 and for an upgrade it's working surprisingly well.
If 16.04 keeps performing as well it is now I will in a few months replace 14.04 with 16.10, etc, etc.

You'd need a ~16GB root and some ~10GB for a /home.
As long as you shut down properly the swap can be shared.
Most of the content of the original /home (Documents, mail and browser) can be linked to it from your original home so the new /home will only need space for configuration files etc.

Unless of course you're using btrfs. Then no partitioning needed. Right GG?

EDIT: As pointed out below; To my knowledge, the need for a swap partition and/or any partition needed for booting (EFI or otherwise) are not obviated by the use of btrfs, or any other file system.

[jlittle]

Unless of course you're using btrfs. Then no partitioning needed.

I was misled by that sentiment - a swap partition, for hibernation, and an EFI partition on UEFI systems, means partitioning is needed for the first install. A bit slow of me to think otherwise, but maybe there's others as prone to taking things literally.


Regards, John Little

[oshunluvr]

John, Technically true, but I was referring to this part of your post:

You'd need a ~16GB root and some ~10GB for a /home.

I should have been more specific or edited the quote properly prior to posting.

More correctly: btrfs does not require partitioning of available usable space in order to have multiple bootable installs and/or a segregated home(s). Therefore, if one were using btrfs, one would not need to re-partition or have or use separate partitions in order to install 16.04 "along side" an earlier release. One would only have to prepare the existing subvolumes as I have outlined here. This was the intended gist of my comment.

I am unaware of any file system that wouldn't require a separate swap partition or can assume the requirements of EFI booting, therefore I didn't feel the need to state something I believed to be self-evident. I apologize if you feel I was misleading.

EDIT: In the spirit of full disclosure; as far as I know at this time, only Ubuntu and it's derivatives install to subvolumes by default when selecting to install to a btrfs file system. Using btrfs with Kubuntu at install time results in two subvolumes; one for the install and one for home.

[Teunis]

I have no doubt btrfs is for these scenario's an excellent option, the subvolumes prevent any slack space being fragmented between old fashioned partitions so you get the best out of your hard disk.

One day I'll upset this computer so badly that I'll have to wipe both Kubuntu installs, that would be the moment to again go btrfs.

Last time is nearly 5 years ago, it worked fine until a kernel upgrade made btrfs incompatible grub update crash, since I'm back on ext4.

[oshunluvr]

Yeah, five years ago the file system format was still being worked on. It hasn't changed since 2014 and there are no plans to change it again. I've been using it since 2010, first as an experiment (btrfs-tools was v0.19 !) but I've been using it as my primary file system for years now. I have a server with 12TB in btrfs and my desktop has 2TB - both using multi-device btrfs pools. Only file corruption I've had was caused by a faulty drive interface that kept kicking one of my drives off-line then back on again every half hour or so. By the time I discovered it, the filecheck reported 4 corrupted files but pointed me right at the inodes that contained them. From there, I identified the files and replaced them with un-corrupted versions and all is well. Only real issue was because of the damaged inodes the file system wouldn't let me delete them. However, I could rename them so I did that and just left them in place. The fsck feature is still new and at that time (2014) it couldn't fix the errors by itself. I haven't tried it again (or needed too) since then.

I keep separate partitions for EFI and swap and I have one ext4 partition that I reserve for virtualbox drive images so I can use dynamic sizing. btrfs, like all other COW file systems that I'm aware of, doesn't handle dynamically sized discs or swap imaging well. All my installs and personal data reside in a btrfs pool which I snapshot when needed and I use btrfs send/receive to make backups. My server drives are imaged using btrfs as a backup method.

Pretty nifty stuff...

[Teunis]

Good you mentioned the Virtual Box thing.

[oshunluvr]

Good you mentioned the Virtual Box thing.

You can actually use virtualbox virtual drives on btrfs, but you need to change a vbox setting (enable "Use host I/O cache" on the VM's SATA controller) and stick to fixed drive size rather than dynamic. Or use a different partition and file system like I am at the moment.

[Teunis]

So far I'm using a fixed size drive of only 10GB to keep a version of 32-bit XP for some oddball but essential 16-bit software.

Ahh, the days of Win3.1 (No not 3.11)

[bendy]

Has anyone tried an in-place upgrade yet from 14.04 to 16.04? If so, how did it go?

[GreyGeek]

Some report success, some report problems, some report failure. IMO, it is always best to back up your data, which is never a wrong thing to do, and do a fresh install from an md5sum (or sha512sum - which ever checksum the site provided) checked ISO, burn it with verification, then install. For sure, it is generally quicker to do an install (20 min to an hour, depending on how many additional apps or data you need to reinstall) than it is to debug an upgrade. IF a fresh install gives you problems most likely it is a bad ISO or burn.