Ubuntu 21.04 is un-upgradeable

[Rob Thomas]

Related: https://bugs.launchpad.net/ubuntu/+source/ubuntu-release-upgrader/+bug/1981939

Any existing U21.04 machines are currently dead in the water, as there appears to be no way at all to upgrade them to 21.10 and then to 22.04.

For some reason 'do-release-upgrade' is trying to take them directly from 21.04 to 22.04 - is there some typo/regexp issue somewhere where it's thinking it's trying to move from 20.04 to 22.04?

[Rob Thomas (xrobau)]

To work around this requires some hacking on /usr/lib/python3/dist-packages/UpdateManager/Core/MetaRelease.py

Around line 312, change the 'continue' to be 'pass'

Was:

                if not dist.supported and not self.useDevelopmentRelease:
                    continue

Needs to be:

                if not dist.supported and not self.useDevelopmentRelease:
                    pass

This is what is blocking 21.04 from picking up the upgrade to impish

[Chris Guiver (guiverc)]

Thank you for reporting this bug to Ubuntu.

Ubuntu 21.10 (impish) reached end-of-life on July 14, 2022.
Ubuntu 21.04 (hirsute) reached end-of-life on January 20, 2022.

See this document for currently supported Ubuntu releases:
https://wiki.ubuntu.com/Releases

The upgrade path worked until the release Ubuntu 21.04 was tested & supported (which was 21.10) to upgrade to reached EOL. The Ubuntu Release Upgrader tool doesn't support, and isn't intended to support upgrading from a non-LTS release after that path has gone. The upgrade path was open for the nine months of Ubuntu 21.10's supported life.

[Rob Thomas (xrobau)]

I accept that Canonical have decided to cripple do-release-upgrade when it is deemed that a release is too old.

Should this not be documented somewhere, EXPLICITLY with how to recover from this?

In your example, on July 13th, a machine could be upgraded from 21.04 to 21.10. On July 14th, the machine was (without this patch) un-recoverable and could never be upgraded to 21.10. Nothing changed, apart from Supported: 1 being changed to Supported: 0 in the meta file.

[Rob Thomas (xrobau)]

My immediate suggestion would be to only skip unsupported OSs if the CURRENT OS is supported.

That would allow someone to upgrade from 20.10 (unsupported) -> 21.04 (unsupported) -> 21.10 (unsupported) -> 22.04 (supported) which would be painful and annoying for the end user, but it would at least mean they can catch up to what Canonical wants.

The code would then be something like:

  if this_dist.supported and not dist.supported and not self.useDevelopmentRelease:
      continue

[Chris Guiver (guiverc)]

EOL upgrades are documented at https://help.ubuntu.com/community/EOLUpgrades, but non QA-tested or unsupported upgrades should be avoided, esp. on data-critical systems.

The use of year.month release names (eg. 20.10 tells you 2020-October release) allows calculating EOL pretty easy (add 9 months to October & you have EOL; add a further 6 months & you have the closing window for the release-upgrade process just from 20.10).

The release-upgrade you wish for is unsupported, isn't quality-assurance tested, and providing a means to do something that is unsupported & not quality tested to me makes little sense, as it makes it easier for people to risk loosing data using unsupported upgrade paths.

FYI: If a user was using Ubuntu 20.04 LTS, then can release-upgrade to the next supported release of Ubuntu; be it 20.10/21.04/21.10 (whilst supported), but for non-LTS users the next release is the only supported/QA-tested path.

FYI: I'm not a Canonical employee.

[Nick Rosbrook (enr0n)]

Rob, this issue is currently being addressed in bug 1975533. A fix has been implemented, and the updated ubuntu-release-upgrader should be available in a week or so.

I am going to mark this as a duplicate of bug 1975533 because I believe your concerns are being addressed there.