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
    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
    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
    Nov 27, 2021 at 13:08
  • Thank you. I try.
    – Shingol
    Nov 27, 2021 at 15:03

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.