Can there be any issue if I edit sources.list and jump between Ubuntu releases?
Why I am asking this -
So I was just learning the ubuntu file system and other things related to bash, where 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 goes 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?
What I want to ask
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.
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.
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)