I faced a problem since I've run the commands in link to upgrade from ubuntu 18.04.6 LTS to 20.04. Unfortunately, I couldn't upgrade. Besides, running those commands broke other things from running.

Can I somehow restore the previous state of my system before running those commands so that my system works well like before?

  • Comments are not for extended discussion; this conversation has been moved to chat.
    – Thomas Ward
    Commented Nov 26, 2021 at 22:20

1 Answer 1


My guess was you've upgraded packages and are no longer running bionic (18.04) but have yet to boot - but in that case I'd still reboot & assess what you're actually running & how the upgrade went...

If Ubuntu (or flavor) Desktop you can fix by re-installing (no-format) which is what I'd likely do if I wasn't sure exactly what was done (I'm not sure!)

guiverc@d960-ubu2:/usr/share/sddm/themes/lubuntu$   rmadison update-manager-core
 update-manager-core | 1:0.196.11    | trusty           | all
 update-manager-core | 1:0.196.25    | trusty-updates   | all
 update-manager-core | 1:16.04.3     | xenial           | all
 update-manager-core | 1:16.04.12    | xenial-security  | all
 update-manager-core | 1:16.04.17    | xenial-updates   | all
 update-manager-core | 1:18.04.11    | bionic           | all
 update-manager-core | 1: | bionic-updates   | all
 update-manager-core | 1: | bionic-proposed  | all
 update-manager-core | 1:20.04.9     | focal            | all
 update-manager-core | 1:  | focal-updates    | all
 update-manager-core | 1:21.04.8     | hirsute          | all
 update-manager-core | 1:21.04.10    | hirsute-updates  | all
 update-manager-core | 1:21.04.11    | hirsute-proposed | all
 update-manager-core | 1:21.10.4     | impish           | all
 update-manager-core | 1:21.10.5     | impish-updates   | all
 update-manager-core | 1:22.04.2     | jammy            | all

If you apt-cache policy update-manager-core you should get update-manager-core | 1: | bionic-updates | allif your system is *bionic* but I suspect you'll get a package more likeupdate-manager-core | 1:21.04.8 | hirsute | all(which would match the *hirsute* lines you pasted in your question) but if you'd gone where you wanted (*focal* or 20.04) you'd seeupdate-manager-core | 1: | focal-updates | all.... ie. you're not running 18.04 at all I believe; the text file of your release doesn't match what you're actually running. I'd explore usingapt-cache, ubuntu-security-status` etc

Also note: In comments I asked you to run ubuntu-support-status which is the bionic command but you got

I get this : "ubuntu-support-status: command not found" and "ubuntu-security-status" runs

which is more confirmation that you're not running bionic with more packages upgraded. Instead your system ran the command which didn't yet exist in 2018; ie. the re-write called ubuntu-security-status.

Ubuntu 18.04 LTS reaches the end of it's standard support life in 2023-April; ie. 5 years from release. Any packages you have of that release will show that as the end of your security updates; though do note 'universe' packages had 3 yeas of support which has already ended for bionic. ubuntu-security-status (or if using 18.04 it's ubuntu-support-status) will give a glimpse of what packages you've likely got (it may not be accurate; but it's an easy way of getting a glimpse of packages that need fixing instead of checking them individually). It might be a lot of work I suspect; why re-installs are usually done, or restoration of our backups.

Much of what you've suggested will only fix your pasted detail on the screen; however it will stop your system getting updates & make it insecure in day(s) instead of month(s). The package I highlighted before shows you've already got hirsute packages installed (1:; they won't receive any updates and bionic updates (1: as even if a newer 1: came out; 18.04.. is not > 20.04... so that package & all your upgraded hirsute packages will require you to manually fix. Your system isn't bionic or 18.04 anymore. Restore your backups (it's why we create/have them), re-install or re-install each package manually.


  • restore your system backups
  • re-install; which is easy for Desktops (I use it myself at least weekly in QA-testing & rather regularly in changing releases as focus changes to a different release (eg. currently jammy [22.04] & focal [20.04.4] are my primary focus) and my Ubuntu packages are re-installed without loss of any data files.
  • manually fix as I've alluded to... this may be a huge job so I'd avoid it; re-install is much easier & cleaner.

This is written based on details you've provided; only two packages have been proven to be hirsute, but that's two of only two looked at - ie. a tiny sample size, but I suspect it's far more than that obviously. You can read the output of the commands I've given, explore using apt-cache policy suggested earlier for random packages & draw your own conclusion which will confirm or other my suspicions

  • large parts of this taken from comments; it's still messy, but loads of comments skipped
    – guiverc
    Commented Nov 26, 2021 at 21:32
  • Sorry I have minimal experience trying to install Ubuntu (server or desktop) remotely. I'm largely a desktop user, and whilst I've performed an install within the last 30 mins (QA-test) it was local so I can see the screen & notice issues etc. I do have & have used server boxes that allow the install to be done remotely (using ILO, IDRAC...) but I haven't used that in some time.. The servers were only a few floors away if I made a mistake though..
    – guiverc
    Commented Nov 27, 2021 at 13:08
  • Thank you. I try.
    – Shingol
    Commented Nov 27, 2021 at 15:03

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .