Upgrade to Linux Mint 19

I have two computers here running Linux Mint (Mate). Both were version 18.3, which Mint stopped supporting at the end of April.

Upgrading Linux Mint isn't as straightforward as upgrading Ubuntu. Until I gave the attached upgrade instructions a shot, I would usually just back up all of my data, and install a fresh copy of Mint.

Pay particular attention to the display manager section on page 2. You must install LightDM and remove MDM if indicated.

On both machines, I backed up my Home folder (including hidden & config files) manually into a tar.gz file. I used Timeshift to create a backup of the system files to an external (ESATA) 500 GB HDD partition formatted to Ext4.

The upgrade ran flawlessly on both machines. My slower machine (Intel Duo-Core + 12 GB RAM) required a little over 2-1/2 hours to complete. The faster machine (AMD FX-8120 8 Core CPU / ASUS Sabertooth 990FX MB, 24 GB RAM) completed the task in just under 2 hours.

You'll be using the 'mintupgrade' tool to do the actual work. It has a "dry run" mode you should use to pick up any conflicts or issues. Once you get a clean "dry run", it's all very easy to complete the upgrade.

Linux Mate 18.3 was very popular, and I'm hoping the attached upgrade instructions will help get any 18.3 users up to 19.3 without a complete re-install.

The URL to the upgrade web page is: https://community.linuxmint.com/tutorial/view/2416

Been running 19.3 for a while now. Hopefully it stay in support for a while to come.

Quote:

---

Originally Posted by N8YX

Been running 19.3 for a while now. Hopefully it stay in support for a while to come.

---

I've been doing new installations with 19.3 for a while, just hadn't gotten around to updating my two 'main' computers. They're pretty consistent on support... version 19.3 will be supported until the end of April 2023.

ETA: Upgrading 19.3 to version 20 is very similar to the upgrade to 19. I just skimmed over one of the many 'upgrade Linux Mint to version 20' step by step web pages. This one appears to offer the clearest instructions:

How to Upgrade to Linux Mint 20 (Step by Step Tutorial)

The version of Oracle's VirtualBox (5.x.x.x) in the Mint repositories of version 18.3 depends on a kernel driver and DKMS to run. DKMS was dropped from VirtualBox following the end of VB 5. There is a work-around, but it's so much easier to purge (sudo apt purge virtualbox*) VB 5, and upgrade to 6.0.x.x or 6.1.x.x) with the ready to run .deb files available for download.

Instructions are in the next to last post on this forum page:

[Kernel driver not installed (rc=-1908)

I always run the latest and greatest VirtualBox version on my main computer. It was on my secondary machine that I caught this hiccup.

I just upgraded both active shack systems from 19,3 to 20.3 today. It went fairly smoothly except for having to reinstall some build tools for flrig/fldigi/wsjtx. Posting on 20.3 Una now.

Quote:

---

Originally Posted by N8YX

I just upgraded both active shack systems from 19,3 to 20.3 today. It went fairly smoothly except for having to reinstall some build tools for flrig/fldigi/wsjtx. Posting on 20.3 Una now.

---

Wait until you upgrade to LM 21.1 Vera. UI facelift is .... interesting. :icon_wink:

A little bump regarding the 20.3 version:

I have a copy of GRLevel3 - the NEXRAD Doppler weather radar analytics and display package. Was running it via WINE (compiled from WINEHQ 7.x sources) or on a Win10 Pro VM on this PC. When run under Tricia 19.3/WINE 7.x, I could get maybe 4h of continuous operation before the program froze up and I had to hard-stop it. Most times, Win10 would run it even less than that before freezing.

When I upgraded this system to 20.3 I removed that version of WINE and all supporting libraries, then installed the version which came in the 20.x repos.

Surprise...GRLevel3 has been running via WINE for almost a week straight now without hiccup.

Another thread bump:

Updated my 20.3 system yesterday, commanded it to restart and it came back up with the never-popular initramfs prompt. Booting into a live USB stick then running fsck on the root partition didn't fix the problem, as there were no errors.

Digging around the 'Net, one finds mention of pre-5.15 kernels having a bug whereas file system errors accumulate and lead to this. Note there's nothing wrong with the drive itself (per SMART diags).

Something to keep in mind. The solution was to pull my data off, reinstall the O/S (which is now 21.3) then add the apps back in (which I'll be doing today).

Upgraded another system to 21.2, then 21.3.

The PC (a DS-61) is used as a VM host and as a backup to my main systems when they're offline (such as now, when I'm redoing my main office). I have 4 of these in total and all 4 will be set up the same. Just the hostnames will be unique. When the others are ready I'll boot this one from a live USB and dd each of their drives. Probably do a 5th drive as a spare in case anything happens to one of the others.

Same goes for my SH61R4/SH170R6 VM hosts. Those will boot from NVMe drives and their data/apps partitions are kept completely separate from the OS itself.