10

After being notified about the 1404_HWE_EOL, I am considering upgrading an important production system to 16.04.1. I say "important production system" because this is the workstation I use daily at work. I want to avoid bugs or other problems because I do not have an excess of time to spend debugging and sorting out issues (the IT department do not help with linux systems). I have all data backed up but not the current OS partition (I may dd the OS drive as another layer of fallback). What other steps should I perform before upgrading up? I want to know how to minimize complications when using the release upgrade offered in Ubuntu.

I have read about removing PPAs before upgrading. I have 27 PPAs installed, it will take some time to remove all of these, the programs they bring, then reverse that after upgrading. Does this have significant benefit? Anything else?

Community
  • 1
Steven C. Howell
  • 1,076
  • Is this production system a VM? If so, you may have an option to take a snapshot and/or revert to it prior to upgrading. I've used this before to avoid failed upgrades on a local development machine (not a production server). – ashes999 Aug 26 '16 at 20:47
  • It is not a VM. In such a case, this would be a great option. – Steven C. Howell Aug 29 '16 at 13:44
  • 1
    When I upgraded, the process automatically disabled my added PPAs — you don't have to remove them. After upgrading, i could re-enable them. Teething problems (for me) were mostly about a couple of PPAs that hadn't been updated to support Xenial. – Paddy Landau Aug 30 '16 at 05:25
  • A caution. If you have an AMD graphics card make absolutely sure that it is compatible with the drivers available in 16.04. Mine is not, and for the benefit of my hardware's longevity, I have returned to 14.04. – Tony Martin Aug 30 '16 at 20:41

4 Answers4

13

important production system

I would not upgrade a system like that. I would install 16.04 on another machine, copy the live data over to that machine. Test, test some more. And then make that machine the production server.

And you can redo this with 18.04 with the current 14.04 server.

Why take risks at all?

Rinzwind
  • 299,756
  • In my situation, I do not have a complete duplicate hardware stack, so this means using dd to clone my drive (SSD to HDD), test both the original and the clone, then nuke and pave to put the new OS on. I have always done this in the past but have been hopeful that following some set of steps provides a reliable method for upgrading to a new release. Is that a too optimistic? – Steven C. Howell Aug 26 '16 at 14:19
  • Nope. Totally possible. 1 thing you might need to take into account: 16.04 uses "systemd". So the startup of all the services have changed. – Rinzwind Aug 26 '16 at 14:25
  • So what steps lead to improved results when using do-release-upgrade to upgrade Ubuntu to the next LTS release? – Steven C. Howell Aug 29 '16 at 13:45
  • While this answer provides sound advice, which in my experience is a safe way to upgrade, it does not provide information on using the built-in release upgrade option. That is what I want to understand better. – Steven C. Howell Aug 29 '16 at 13:52
  • Sorry,"improved results when using do-release-upgrade" compared to what? – Rinzwind Aug 29 '16 at 13:52
  • Other than backing up a system, are there active steps to perform so do-release-upgrade will work without issues, the way the Ubuntu developers intended? Are there installed packages I should remove (maybe those from PPAs), settings I should return to default values, etc? I expect the Ubuntu developers test do-release-upgrade on a vanilla installation, maybe a few other test cases, but every real system is different making it impossible for the upgrade process to be completely robust. I expect bringing my system closer to a vanilla installation decreases complications but is that true? – Steven C. Howell Sep 08 '16 at 17:36
2

I would take an Image Backup ("dd" in a Linux Live System) of the Workstation and convert this to a VirtualBox VM. (RAW-Image to VDI). After that make a snap and run this Image in VB. Play all the step to upgrade. If something isn't working put the snap back. After having a upgraded system you can convert the VDI back to raw and "dd" it to your system or play the run-book.
But always make a last "dd" Image backup before you overwrite your old system.
I prefer to run my systems from a USB Thumb-drive so system-install is done with "VDI - >RAW -> usb tumb-drive" and boot from the upgraded/installed system. ready. Okay you "loose" one USB port but you never will have stress and you can alway do easy a system-backup. I do this with my workstation and servers in production for years now.

0x0C4
  • 713
1

Here's a variation of @rinzwind's answer that might work with the hardware you already have.

If you have (or can free up) enough free space on your internal disk drive(s), you can create 2 new partitions (using something like gparted from a live CD/USB distro) and copy root (/) to one of them and /home to the other and label them something like root2 and home2 so they're easy to find.

If root and home are in the same partition, you can just copy that, but it's a whole lot nicer for many reasons if they're separate.

You'll have to point the new root at the new /home by editing the changes into /etc/fstab on the new root partition (updating the UUIDs of the new /home and root partitions).

You get them by doing an ls -l /dev/disk/by-label to find the devices the new root and home are currently on and then running ls -l /dev/disk/by-uuid to get from the device names to the uuids.

Next, update grub (from your production system) with something like grub-customizer to add the new root to your grub menu.

Now, you'll have an exact copy of your live system on those partitions. You can run the upgrade on this copy and still have the production version intact. You can boot into whichever one you want to work on.

Once you're done with the upgrade, you can just tell grub that the copy is the live one (default entry) and that the original is now the backup. grub-customizer makes doing things like this fairly easy.

If you have too much data in /home or root (making them too big to duplicate), put it in its own partition first (being sure to tell the programs that access it about the move). It doesn't need to be duplicated - just backed up.

This also makes backing up your data a lot easier because it's no longer mixed in with system stuff.

With a second set of "test" partitions, you can now try all sorts of things you wouldn't want to risk on the system you depend on for day to day work.

I'm currently running Kubuntu 12.04 like this with 16.04 in my "development" partitions until it's configured the way I want it.

With disk drive prices so low these days, you could even copy your existing internal drive to a new larger one and use that if necessary - if your company will let you.

This answer covers all the major details of how to do this. I didn't try to cover every small detail of each step. But since you're working with a copy of everything there shouldn't be any serious issues and everything else has already been covered somewhere here on stackexchange.

Joe
  • 1,884
0

Although this doesn't apply to your specific case, if the Ubuntu system is a VM, you can get around this problem by taking a snapshot before upgrading and reverting if it doesn't work.

I once upgraded one of my VMs, and although the upgrade failed and supposedly rolled back, I didn't get a clean/functional system.

@Rinzwind's answer also works with VMs: create a new VM, install the new Ubuntu version on it, and start copying things over.

ashes999
  • 177
  • 2
  • 10