Score:0

restore my system

tm flag

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 like apt-get update and many other commands. For example, bu running 'sudo apt-get update', I get the following error:

Get:1 http://security.ubuntu.com/ubuntu hirsute-security InRelease [110 kB]
Hit:2 http://us.archive.ubuntu.com/ubuntu hirsute InRelease                                                                  
Hit:3 http://dl.google.com/linux/chrome/deb stable InRelease                                                                                           
Get:4 http://us.archive.ubuntu.com/ubuntu hirsute-updates InRelease [115 kB]                                                                           
Ign:5 https://esm.ubuntu.com/infra/ubuntu hirsute-infra-security InRelease                                          
Ign:6 https://esm.ubuntu.com/infra/ubuntu hirsute-infra-updates InRelease         
Err:7 https://esm.ubuntu.com/infra/ubuntu hirsute-infra-security Release
  404  Not Found [IP: 91.189.88.182 443]
Err:8 https://esm.ubuntu.com/infra/ubuntu hirsute-infra-updates Release
  404  Not Found [IP: 91.189.88.182 443]
Get:9 http://us.archive.ubuntu.com/ubuntu hirsute-backports InRelease [101 kB]
Reading package lists... Done     
E: The repository 'https://esm.ubuntu.com/infra/ubuntu hirsute-infra-security Release' does not have a Release file.
N: Updating from such a repository can't be done securely, and is therefore disabled by default.
N: See apt-secure(8) manpage for repository creation and user configuration details.
E: The repository 'https://esm.ubuntu.com/infra/ubuntu hirsute-infra-updates Release' does not have a Release file.
N: Updating from such a repository can't be done securely, and is therefore disabled by default.
N: See apt-secure(8) manpage for repository creation and user configuration details.

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

I would be grateful for any help.

ru flag
Comments are not for extended discussion; this conversation has been [moved to chat](https://chat.stackexchange.com/rooms/131817/discussion-on-question-by-mar-z-restore-my-system).
Score:2
cn flag

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:18.04.11.13 | bionic-updates   | all
 update-manager-core | 1:18.04.11.14 | bionic-proposed  | all
 update-manager-core | 1:20.04.9     | focal            | all
 update-manager-core | 1:20.04.10.9  | 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:18.04.11.13 | 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:20.04.10.9 | 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:20.04.10.9); they won't receive any updates and bionic updates (1:18.04.11.13) as even if a newer 1:18.04.11.14 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.

Summary

  • 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

guiverc avatar
cn flag
large parts of this taken from comments; it's still messy, but loads of comments skipped
Mar z avatar
tm flag
Can I reinstall remotely? I only have access to the system remotely (via ssh and remote desktop connection) and I only have ubuntu installed. I think there is no backup!
guiverc avatar
cn flag
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..
Mar z avatar
tm flag
Thank you. I try.
mangohost

Post an answer

Most people don’t grasp that asking a lot of questions unlocks learning and improves interpersonal bonding. In Alison’s studies, for example, though people could accurately recall how many questions had been asked in their conversations, they didn’t intuit the link between questions and liking. Across four studies, in which participants were engaged in conversations themselves or read transcripts of others’ conversations, people tended not to realize that question asking would influence—or had influenced—the level of amity between the conversationalists.