The traditional way to upgrade Ubuntu 18.04 LTS to 20.04 LTS without waiting for the release of Ubuntu 20.04.01 - command do-release-upgrade with the key -d. But this method has been repeatedly criticized in responses and comments on this site (for example, here). Recently, I came across a different method on the Internet:

sed -i 's/bionic/focal/g' /etc/apt/sources.list
apt-get update
apt-get upgrade
apt-get dist-upgrade

This method, unlike the traditional one, does not have negative reviews (perhaps because it is less well-known). I tried both methods on the VM and both of them led me to get a system similar to Ubuntu 20.04 LTS (at least at first glance):

# uname -rv
5.4.0-29-generic #33-Ubuntu SMP Wed Apr 29 14:32:27 UTC 2020

# lsb_release -a
No LSB modules are available.
Distributor ID: Ubuntu
Description:    Ubuntu 20.04 LTS
Release:    20.04
Codename:   focal

# cat /etc/os-release
VERSION="20.04 LTS (Focal Fossa)"
PRETTY_NAME="Ubuntu 20.04 LTS"

But which one should I choose to upgrade my production server? I understand that the ideal answer is to wait for July 23 (release date of Ubuntu 20.04.01), but what if I need to get the result right now? Which of the two evils described above is the lesser?

  • 4
    That method has been criticized far more than other methods because it treats Ubuntu as if it's Debian, completely ignoring the additional python tooling Ubuntu built in, and thus timing of the do-release-upgrade that ensures the order of upgraded packages is controlled to prevent issues.. That method is untested, unsupported for Ubuntu. (it was popular in the early days of Ubuntu if you look back... it was then ignored as safer methods of upgrade became the norm... I'm guessing you didn't look back very far) Ubuntu is not Debian (much as I commonly think of the two as very alike) – guiverc May 7 at 2:15
  • 1
    Hmmm. I wrote that answer you linked to. I wasn't intending to criticize the use of -d, but merely to clarify the reasons why it should/shouldn't be used by most folks in frequently-encountered circumstances. If you look through the threads here, you will find many tools getting misused by folks, even something as seemingly foolproof as do-release-upgrade. – user535733 May 7 at 2:16
  • FYI: I did used that method of upgrade to bump my then 20.04 box to 20.10 on 25-Apr-2020 (my local time, about 36 hours after 20.04 was officially released), but given the groovy was so new, almost no (okay six) packages it's easy to check for package timing issues that can be problematic.. and it's about the only option that early in the cycle anyway.. It still is used, but it's a user-beware case so you should be aware of it's pitfalls. – guiverc May 7 at 2:22
  • @guiverc, your first comment contains the information I was looking for. If you post it as an answer, I will accept it. – Ivan Olshansky May 7 at 2:25

Ubuntu is not Debian (despite how many of treat it as if it is; myself included).

Ubuntu tools very much rely on python, more so than Debian. As such there is more critical issues with python packages in Ubuntu than in Debian.

Ubuntu tools ensure upgrades occur in an order that won't create issues, and have been tested for this (such as ensuring python is upgraded at the right time) which the Debian upgrade method (changing sources and then a dist-upgrade) does not. I'm using that as example.

It also has other pitfalls mitigated, eg. if you're using a terminal on a GUI, and screensaver kicks in during the dist-upgrade setup in your question, you may have lost access to your terminal if screensaver had activated due to timeout unless you disabled it before hand (but you knew that of course and wouldn't have been caught out). The update-manager Ubuntu tool does that for you (unless you've heavily modified your environment beyond what it caters for).

If you want the best method to upgrade, refer to the release notes for the release you want to move to, in this case Ubuntu 20.04 LTS or https://wiki.ubuntu.com/FocalFossa/ReleaseNotes

It has a section titled "Upgrading from Ubuntu 18.04 LTS or 19.10" which contains the instructions that were well tested, and any problems encountered by testers have been documented (in the release notes if critical enough, otherwise on bug reports on launchpad but you'll be very unlikely to hit any of these).

FYI: Is the debian method still used, yep. Used it myself about 36 hours after 20.04's release to bump myself to 20.10 on this box; but I only had ~six packages to peruse and look for potential pitfalls, and since most were just text files containing the release name(s) etc I decided in my case it wasn't a problem. If you're capable of doing this evaluation, then by all means use it, but a bump from 18.04 to 20.04 will contain more than my ~six packages, and will contain many critical packages where my upgrade had none.

This answer is general in nature; my chosen examples are just that - examples and incomplete & simplified.

Ubuntu 20.04.1 Release date

Also note the scheduled date Thursday 23-July-2020 date is for the release of the 20.04.1 ISO (for new installs), the taps to allow installed systems to upgrade is unlikely to occur until the following Monday-Tuesday (even Wednesday..) and if issues occur with new installs that tap turn date is likely to pushed back a little longer, so don't lock on expecting it on that date.

| improve this answer | |
  • FYI: In my Debian method example, I also don't sed my sources, instead I manually review what's in my sources.list files, and remove/edit/etc. It's a twice yearly review (Apr & Oct) where I can remove team PPAs I've added during a cycle to test packages prior to them reaching -proposed for team members. Most just get commented out given it's a new dev cycle. – guiverc May 7 at 5:39

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.