11

I found that sources.list in /etc/apt is the key file for all the repositories.

I also found that every system and ubuntu release has its own sources.list, So here is where I was a little bit in an experimental mood!

I was on Ubuntu 18.04 LTS(64 bit), While just browsing and seeing different sources.list files. In which I found something interesting. So, as of now, there are a lot of new ubuntu versions that had just arrived. I was willing to upgrade mine too to 21.04 ( because of gnome 40)

So I found that I can upgrade ubuntu by the sudo do-release-upgrade command but that command Will go to the next release, instead of the latest release. So that was Very time consuming and internet consuming (I don't have like 20GB of the internet)

The only way I found was to Reinstall from ISO, But I don't want to refresh all data or packages as they also take a little time to install.

So what I did is a little stupid, I changed the contents of my sources.list to -

#deb cdrom:[Ubuntu 21.04 _Hirsute Hippo_ - Release amd64 (20210420)]/ hirsute main restricted

See http://help.ubuntu.com/community/UpgradeNotes for how to upgrade to


newer versions of the distribution.


deb http://us.archive.ubuntu.com/ubuntu/ hirsute main restricted


deb-src http://us.archive.ubuntu.com/ubuntu/ hirsute main restricted


Major bug fix updates produced after the final release of the


distribution.


deb http://us.archive.ubuntu.com/ubuntu/ hirsute-updates main restricted


deb-src http://us.archive.ubuntu.com/ubuntu/ hirsute-updates main restricted


N.B. software from this repository is ENTIRELY UNSUPPORTED by the Ubuntu


team. Also, please note that software in universe WILL NOT receive any


review or updates from the Ubuntu security team.


deb http://us.archive.ubuntu.com/ubuntu/ hirsute universe


deb-src http://us.archive.ubuntu.com/ubuntu/ hirsute universe


deb http://us.archive.ubuntu.com/ubuntu/ hirsute-updates universe


deb-src http://us.archive.ubuntu.com/ubuntu/ hirsute-updates universe


N.B. software from this repository is ENTIRELY UNSUPPORTED by the Ubuntu


team, and may not be under a free licence. Please satisfy yourself as to


your rights to use the software. Also, please note that software in


multiverse WILL NOT receive any review or updates from the Ubuntu


security team.


deb http://us.archive.ubuntu.com/ubuntu/ hirsute multiverse


deb-src http://us.archive.ubuntu.com/ubuntu/ hirsute multiverse


deb http://us.archive.ubuntu.com/ubuntu/ hirsute-updates multiverse


deb-src http://us.archive.ubuntu.com/ubuntu/ hirsute-updates multiverse


N.B. software from this repository may not have been tested as


extensively as that contained in the main release, although it includes


newer versions of some applications which may provide useful features.


Also, please note that software in backports WILL NOT receive any review


or updates from the Ubuntu security team.


deb http://us.archive.ubuntu.com/ubuntu/ hirsute-backports main restricted universe multiverse


deb-src http://us.archive.ubuntu.com/ubuntu/ hirsute-backports main restricted universe multiverse


Uncomment the following two lines to add software from Canonical's


'partner' repository.


This software is not part of Ubuntu but is offered by Canonical and the


respective vendors as a service to Ubuntu users.


deb http://archive.canonical.com/ubuntu hirsute partner


deb-src http://archive.canonical.com/ubuntu hirsute partner


deb http://security.ubuntu.com/ubuntu hirsute-security main restricted


deb-src http://security.ubuntu.com/ubuntu hirsute-security main restricted


deb http://security.ubuntu.com/ubuntu hirsute-security universe


deb-src http://security.ubuntu.com/ubuntu hirsute-security universe


deb http://security.ubuntu.com/ubuntu hirsute-security multiverse


deb-src http://security.ubuntu.com/ubuntu hirsute-security multiverse


This system was installed using small removable media


(e.g. netinst, live or single CD). The matching "deb cdrom"


entries were disabled at the end of the installation process.


For information about how to configure apt package sources,


see the sources.list(5) manual.

Source

Then I ran

sudo apt update && sudo apt full-upgrade && sudo apt dist-upgrade

Then My system and everything was changed to 21.04

So that was a little bit of big brain probably?

Will this harm my system? Are there some benefits? What can go wrong?

  • All my packages were upgraded and new packages were installed.

  • My system is up to date

  • I just want to know if this could be harmful or could do something bad.

  • To be honest, it took only 1804 Mb to upgrade so it is much lighter.

  • Till now (used for two hours) there is no issue.

Error404
  • 7,440
  • 1
    Yes it can work, but it can also fail. Ubuntu isn't debian, and has tools to release-upgrade your system (and ensure success). You can also re-install without losing any datafiles, and have the re-install auto-add back your additional packages (ie. those marked manually installed); I do it regularly as I'm involved in QA-testing, and use a re-install for boxes used for support purposes (also some of my own) as it upgrades my system & does it via a QA-test install. (the upgrade via re-install will also go backwards, but some homework can be involved to ensure no data issues) – guiverc Nov 04 '21 at 10:50
  • 2
    Personally, I think what you're doing is a bit silly. You're saying that a do-release-upgrade a version at a time is "time consuming". That's true. But by doing something like this, you could end up using more time. And not just more time, more of your own "human-time". If you did a do-release-upgrade multiple times, you run the command, answer "yes" a few times, and you let it do its job. So...I don't think you're properly weighing the pros and cons of your decision. You're also doing something that few people do, so if you're stuck, very few people here can help you... – Ray Nov 04 '21 at 10:58
  • Does this answer your question? Can I skip over releases when upgrading? – karel Nov 04 '21 at 11:34
  • 4
    Thanks for the offer, but I just wanted to help you out and wasn't after any reputation. Good luck to you! – Ray Nov 04 '21 at 12:11
  • 2
    I want to ask that if I am on 16.04 or a 32 bit ubuntu release will this method work (upgrade to 21.04 which is 64bit). -- No, you can't upgrade that way. – Archisman Panigrahi Nov 05 '21 at 05:15
  • For my x86 / i386 systems, I performed the upgrade via re-install or install using existing partition I described in my answer to switch them from i386 to amd64 (as it's a re-install & system directories are wiped; it allows architecture change). More details can be found https://discourse.lubuntu.me/t/testing-checklist-understanding-the-testcases/2743 maybe (see install using existing partition which I talked about for QA-test installs... my old favorite Ubuntu 11.04 i386 box still lives & gets used in QA-tests semi-regularly; my last box with 3.5" FDD i think) – guiverc Nov 05 '21 at 05:26

2 Answers2

23

Congratulations, you have discovered the original Debian method of migrating between Debian releases: editing sources and then running dist-upgrade.

The Ubuntu do-release-upgrade method uses dist-upgrade under the hood, but also includes some additional features that most users can appreciate:

  • Standardized new sources.list, and automated editing of that file.
  • Disabling of PPAs to prevent broken upgrades.
  • Autoremove after the new package installs.
  • Scripted migrations when required.
  • Snap refresh
  • Common upgrade paths are repeatedly tested and debugged by volunteers during pre-release

Could this be harmful or could do something bad?

Sure. If you use an unwise set of new sources, you can easily break your system.

Apt is a great and elegant tool, but it's not smart. It will try to do exactly what you order it to do, regardless of how foolish that order might be.

It's quite possible to use dist-upgrade to ride an untested path between releases -- like from 20.04 to 21.10. Apt will do it. But it's not tested. Maybe it will work well; maybe it won't. You might encounter unexpected problems that nobody else can reproduce. We didn't test it (that's what "untested" means). YOU are testing it.

Generally, debugging severe failures caused by untested dist-upgrades is a waste of everybody's time -- certain paths are tested and supported; off those marked paths you are on your own. It's faster and easier to simply re-install the desired release of Ubuntu instead. If you pay attention during the install process, you can overwrite Ubuntu while preserving your data.

If a group of dist-upgrade enthusiasts want to get together and debug additional upgrade paths and provide support, they are welcome to. The current system is determined by the number of volunteer testers and developer hours available.

user535733
  • 62,253
9

Yes it can work, but it can also fail. Ubuntu isn't Debian, and has tools to release-upgrade your system (and ensure a higher chance of success).

I use the development release on this box (ie. currently jammy); and usually bump myself about 30 hours after the release of the prior development release (or when needed archives are setup, base-files & a few key packages are ready to go). If the do-release-upgrade -d hasn't been setup (which is quite often), I do what you did to bump this box. I do some checks before I do it of course; so your success rate may depend on what checks you perform (many of these checks and more [eg. ensuring packages are upgraded in the correct order] are done via do-release-upgrade & upgrade-manager).

You can also re-install without losing any datafiles, and have the re-install auto-add back your additional packages (ie. those marked manually installed); I do it regularly as I'm involved in QA-testing, and use a re-install for boxes used for support purposes (also some of my own) as it upgrades my system & does it via a QA-test install. (the upgrade via re-install will also go backwards, but some homework can be involved to ensure no data issues). eg. when groovy or 20.10 reached EOL; I just did a impish QA-test install to make that install my 21.10 support box (a fast install achieved what would have been 2x do-release-upgrade steps; I lost no music, my chosen music player (which isn't installed by a default install) etc. and in a fraction of the time required, and completed a QA-test too). Installs don't need to be destructive -- however that doesn't mean you shouldn't have backups; it's easy to make mistakes.

FYI: If the box is on a development release (excluding this my main PC); I don't actually upgrade those systems, but upgrade via re-install so again I can cross off a QA-test at the same time as upgrading my packages.. Development releases currently are jammy & focal (ie. the next 20.04.4 release). I also in recent months had a box switch from 21.04, to impish/21.10 back to 20.04.3, to 21.10.. some paths not being possible via release-upgrade, nor your modification of sources! and I didn't lose any music, nor any packages I'd manually installed (experience can vary when 3rd party packages are used; on QA-boxes I avoid 3rd party packages)

guiverc
  • 30,396
  • 2
    This detail only briefly touches on the question (it's my comments cleaned slighty); but primarily addresses the OPs remark "The only way I found was Reinstall from ISO , But I don't want to refresh all data or packages as they also take a little time to install" which I disagree with... the re-install option is something I love about Ubuntu :) – guiverc Nov 04 '21 at 12:18
  • 2
    “usually bump myself about 30 hours after the release of the prior development release” — You can replace the animal name in your sources.list with ./devel to run a perpetual beta and pretend Ubuntu is Debian Sid. The best thing is that it also works with Launchpad PPAs — it aliases to the latest available (either stable or development) release on that particular repo. – kinokijuf Nov 05 '21 at 11:07
  • 1
    Thanks @kinokijuf but I use the manual bump every six months to review my sources; clean up any team PPAs I added during the cycle & remove any software that didn't make it into official Ubuntu repositories (unless pushed for next release). Manually bumping suits my routine perfectly (I do it only after I've done my clean) – guiverc Nov 05 '21 at 21:16
  • Sounds like we have different use cases. I don't do linux package development or QA, I just want to use something resembling debian sid on a workstation, and actual debian has older packages and worse community support. – kinokijuf Nov 07 '21 at 18:24
  • FYI: another benefit of the Ubuntu release-upgrade tools is avoiding known pitfalls; eg. if a desktop system and you're upgrading (the debian way) on GUI, it's possible for the screensaver to kick in & you're unable to unlock the screensaver (due change in packages), the screensaver is disabled whilst Ubuntu upgrade tools operate to prevent this potential issue that may cause a user to think they've lost control of their machine (they can't unlock screensaver) & thus reboot creating issues (the reboot being the problem)... There are many tiny issues it avoids... example only. – guiverc Nov 30 '21 at 11:00
  • You use do-release-upgrade & like tools to upgrade you from one release to the next release (ie. 20.04 to 20.10 if it was supported; otherwise it'd go to 21.04 currently) OR to the next LTS release; ie. 20.04 will allow upgrade direct to 22.04 after 22.04.1 has been released (key is after; releases always occur Thursday; but upgrade path usually doesn't open till following Monday/Tuesday though can be enabled later too). Users of 21.04 will/should do-release-upgrade (or update-manager) to upgrade to 21.10 in the next days/weeks (it reaches EOL on 20-Jan-2022) – guiverc Jan 01 '22 at 09:01