Canonical preps security lifeboat, yells: Ubuntu 12.04 hold-outs, get in

Re: Interesting situation

Oh, you'd be surprised. I work for Red Hat. RHEL 4 (released 2005) is still in extended support until the end of this month (and we're likely to still have people using it on 'bespoke' support deals after that).

Re: On the plus side

The distro-upgrade usually only works if you have a fairly simple mount arrangement, I have tried it and sometimes it works a charm, other time it failed miserably on machines with odd mounting setups and/or MD RAID in use.

My advice is always put /home on a separate partition, and if you have the space leave a blank ~50GB one as well. Next distro comes along, install it in the unused partition, and once working edit its /etc/fstab file to mount your old /home partition again.

Once happy, you can overwrite your old root partition when yet another new distro is available.

Re: On the plus side

Do they make it easy now? in the past it was not a supported path to do a major version upgrade. I upgraded my company's systems from 10.04 to 12.04 years ago and the process at the time was entirely unsupported, and it took many hours of trial and error to get a robust way to do the upgrade.

Debian by contrast (debian user since 1998) has always(as far as I know) supported major version upgrades. I believed since Ubuntu was based on Debian it should of been possible to do a major version change on Ubuntu even if it wasn't supported (thankfully we have VM level snapshots where I was able to test, break, revert snapshot, test break, revert snapshot until I figured it out)

And for those more techie, to give an example as what I had to do to do the upgrade, here is a snip from the script:

------

export DEBIAN_FRONTEND=noninteractive

debconf-set-selections /mnt/scratch/tmp/ubuntu-upgrade/precise.preseed

apt-get -y -o Dpkg::Options::="--force-confdef" -o Dpkg::Options::="--force-confold" upgrade

debconf-set-selections /mnt/scratch/tmp/ubuntu-upgrade/precise.preseed

apt-get -y -o Dpkg::Options::="--force-confdef" -o Dpkg::Options::="--force-confold" install dpkg util-linux

apt-get -y -f install -o APT::Immediate-Configure=false python2.7-minimal passwd

debconf-set-selections /mnt/scratch/tmp/ubuntu-upgrade/precise.preseed

apt-get -y -o Dpkg::Options::="--force-confdef" -o Dpkg::Options::="--force-confold" dist-upgrade

debconf-set-selections /mnt/scratch/tmp/ubuntu-upgrade/precise.preseed

apt-get -y -o Dpkg::Options::="--force-confdef" -o Dpkg::Options::="--force-confold" install nsca-client

apt-get -y -o Dpkg::Options::="--force-confdef" -o Dpkg::Options::="--force-confold" install nfs-common

apt-get -y install vmware-open-vm-tools-kmod-3.2.0-41-generic

dpkg --purge linux-headers-2.6.32-37 linux-headers-2.6.32-37-server linux-image-2.6.32-37-server vmware-open-vm-tools-kmod-2.6.32-37-server

apt-get -y autoremove

dpkg --get-selections | grep deinstall | awk '{print $1}' |xargs dpkg --purge

-----------

It wasn't a simple apt-get dist-upgrade by any stretch ! I had to upgrade those named packages in that order else the upgrade would not complete. There was more to the script but that was the core dpkg stuff I used to upgrade from 10.04 LTS -> 12.04 LTS. I recall an earlier version of Ubuntu was it 7 or 8 maybe I had installed on my sister's laptop, I went through their GUI dist upgrade on that system and it mostly worked but still required some command line magic to get it to complete(I think it got halfway done and when I rebooted X was broken turns out there was a hundred or so packages that did not upgrade the first time round). Had a similar experience upgrading Mint recently on one of my laptops (I believe I read mint has a no upgrade policy too, though in the Mint experience I just clicked the upgrade button it wanted me to click on to upgrade, so I think that should of worked).

I remember back in the early days of Fedora where they had 6 month cycles(maybe still do haven't had to use Fedora since 2007) they too had a no upgrade policy, and I think back then it was far more dicey to upgrade Fedora rather than reinstall, though I think I read in recent years that it is possible to do major version changes in fedora without reinstalling.

Re: On the plus side

I've tried upgrades of 3 12.04 machines. 1 was successful. 1 thinks it's 14.04, but the upgrade failed and I have one that all of the libraries and files for 14.04 installed, but it thinks it's 12.04. Upgrading is not all that painless. Both of those machines do not behave very well as guests. They're both about to be wiped.

Re: Also

Where did you get Mint 18.3? I'm still on 18.1

Re: Same old story

16.04 is the obvious way to go...but it has stupid systemd-related problems that are still not fixed "out of the box" a year on. Such as:

NTP failing because ntpdate is taking longer https://bugs.launchpad.net/ubuntu/+source/ntp/+bug/1577596

Shut-down/reboot scripts hanging for ~1m30 https://bugs.launchpad.net/ubuntu/+source/systemd/+bug/1594658

Stuff added in /etc/modules being ignored because its in a blacklist (e.g. watchdog drivers) which is fscking stupid - blacklisting is supposed to only apply to auto-detected modules. https://bugs.launchpad.net/ubuntu/+source/systemd/+bug/1535840

Re: Systemd

Would be very interesting to know how many takers there are...This would be a useful metric to see if everybody jumped ship too early, and if there is a potential for Devuan.

Re: Poetterix beckons

Here we go again. We've had mainstream distros using the dreaded 'systemd' for a while now and hey, the world hasn't ended yet.

It is just different from the old system.

I have to own up to abusing the old ini system in the past. You could hack it to your hearts content.

I had to do that because of the limitations of it. Remember the Unix world was a very different place when the old init system was designed.

Things are very much more complex these days and we needed something new.

So far (touch wood) I've had no issues with systemd.

Only time will tell if it is a step (or several) steps too far but for most Distros, there is no going back.

Re: Poetterix beckons

And the gods help you if your system isn't EN-*. Systemd's config parser will shit the bed if one of your config files contains a character not in the ASCII set, even if those characters are in comments or other free-text fields (Like in email addresses or someone's name)

Had a headless / remote server die on me because of that. SysV worked quite well with non-latin characters (Specifically 'ø', which exists right in the middle of my name...). The configuration file was updated automatically from our config management system (and had my name and version/date information in comments at the top).

Since none of our systems -require- Linux, we've been moving everything over to non-systemd Open/FreeBSD (everything either has a BSD package for it or the code will compile just fine on BSD)