22.04 LTS In-Place Upgrade?

I recall reading the early releases of the 22.04 LTS releases were a little wonky, so I held off upgrading my system from 20.04 LTS. I'm reluctant to perform an in-place upgrade even though I'm periodically prompted to do so. I like the LTS releases, but it disturbs me that MATE is only supported for three years, not five. I'm now on the third, and soon-to-be unsupported release, so I have to plan on upgrading. I have a 20Tb file system, and even though most of that is on its own file system mount point, everything is physically located on a single RAID array, so I'd hate to risk everything if I botch the upgrade.

Suggestions, anyone? Tips? Helpful advice?

Hi not addressing concern about upgrade risk. I have UM22.04.2 which I installed at release and since has updated to point 2 version. Do not have raid.But if going to 22.04 which was released in April 2022 there would only be two years left of MATE support while the Ubuntu portion would be good to April 2027. Your 20.04 will still have Ubuntu portion support till April 2025. MATE has to gear up to support upcoming releases of Ubuntu with a fixed amount of developers and testers.


1 Like

One other point. The new Ubuntu Pro, which is available for personal use for free (up to 5 machines) will extend full support for the ubuntu core to ten years. That would be everything except the mate desktop software (pluma, caja, calculator, etc.) Firefox, LibreOffice, and nearly everything else are in common with regular Ubuntu, and are covered under Ubuntu Pro.


The three years was increased to five for Ubuntu Desktop, Ubuntu Server, Ubuntu Cloud & Ubuntu base, with all flavors remaining unchanged. Flavors never decreased support, it was extended only for Ubuntu's main products.

I don't know your system, what app mixture you have installed (ie. what third party applications you have etc) and these (plus your hardware) really influence the result. Thus I'll provide only my 2c thoughts.

  • My primary backup strategy if things go wrong in a release-upgrade is to just non-destructively re-install.

    My last such non-destructive re-install was less than two days ago, I performed as a QA-test install of Lubuntu jammy using the daily. This install performed the Quality Assurance test using the current daily with my checking everything was perfect, but also achieves a apt full-upgrade on the system where I don't normally perform upgrades on; thus does both.

    Ubuntu flavor products are real easy at this (with some caveats where 3rd party packages are used depending on the sources of those packages). The Lubuntu testcase I was performing can be viewed here and its the "Install using existing partition" testcase, but it works on all flavors using either the ubiquity or calamares installer. Its easier with flavors due to them having 'universe' enabled by default too.

    I perform that re-install ~weekly, and very soon my current 22.10 or kinetic system I keep currently for 'support purposes' will become a mantic install testbed, ie. I'll just use the current daily of mantic and thus the current 22.10 system will become 23.10 with my manually installed packages re-installed for me, none of my datafiles I'll confirm will be lost. It's this method that had my once hirsute (21.04) system become jammy (22.04) (the system has many installs, and as one approaches EOL/EOSS it becomes the next development release)

    Yeah I'm talking about Lubuntu here.. but I'm heavily involved with that team if you look, and the install method I'm talking about works for all flavors of Ubuntu. To me this non-destructive re-install method is a fallback if my release-upgrades have troubles, or in fact, if I decide I have insufficient disk space, am in a hurry or many other cases too this method becomes my primary means of achieving an upgraded system.

    Do note: all QA testing of this install method does not include 3rd party software, which can both work with this method, but also fail to work, depending on how it was packaged. If I use this on my own systems, I always evaluate what's installed & decide if I should remove those packages (to ensure the new install will be troublefree) and re-install the apps after the re-install has completed, or decide I need to other testing (setup a VM or spare machine & test the re-install there).

  • It's easy to make mistakes, so always have good backups.

  • For really complex situations, I tend to view this re-install as a backup fix should I have problems with the release-upgrade. Depending on what package changes you've made, your results may differ (eg. if I have a problem with a package & decided to fix via an apt install --reinstall, I'd always reset the manual flag to what it was before hand for that package and not just ignore that my --reinstall changed that package flag).


I'm running Mate systems 16.04, 20.04 and 22.04. The only reason I'm not still running 16.04 on all of them is because needed libraries for newer development tools are not available for it. Its the third party tools that force me to upgrade, not the the Mate desktop stuff. Frankly I see little actual improvement in the Mate components going from 16.04 to 20.04 to 22.04 and many inconveniences over 16.04. I wish developers would pay attention to the old maxim "Different is not better, better is better. if you can't simply explain why it is better then odds are it is not better". Adding stuff I probably will never use is OK as long as you are not changing or removing "old" things that I actually do use.

For me the problem would be non-existent if grub/burg/whatever didn't make multiboot systems such a PITA it maintain, "modern" BIOS that can take an absurd amount of time to actually attempt to boot the system don't help. Ideally I could have a drive, SSD, NVMe in a carrier and simply swap it out to boot the different system, but good luck with that the BIOS fights you every time and laptops make changing a drive like major surgery.