Join Log in
Score:8
Someone avatar Ubuntu

Can there be any issue if I edit sources.list and jump between Ubuntu releases?

my flag
Someone

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.

1101
0 + 0
apt
guiverc avatar
cn flag
guiverc
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)
1
Reply
cn flag
Ray
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...
2
Reply
karel avatar
sa flag
karel
Does this answer your question? [Can I skip over releases when upgrading?](https://askubuntu.com/q/34430/)
0
Reply
cn flag
Ray
Thanks for the offer, but I just wanted to help you out and wasn't after any reputation. Good luck to you!
4
Reply
us flag
Archisman Panigrahi
`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.
2
Reply
guiverc avatar
cn flag
guiverc
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)
0
Reply
Score:16
user535733 avatar Ubuntu
cn flag
user535733

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.

0 + 0
Axelfoley avatar
gb flag
Axelfoley
Thanks for "YOU are testing it!". Made my day after a long day! X-)))
0
Reply
Score:9
guiverc avatar Ubuntu
cn flag
guiverc

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)

0 + 0
guiverc avatar
cn flag
guiverc
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 :)
2
Reply
kinokijuf avatar
gb flag
kinokijuf
“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.
2
Reply
guiverc avatar
cn flag
guiverc
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*)
1
Reply
kinokijuf avatar
gb flag
kinokijuf
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.
0
Reply
guiverc avatar
cn flag
guiverc
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.
0
Reply
guiverc avatar
cn flag
guiverc
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)
0
Reply
ธงชาติไทย
Elon Musk
I sit in a Tesla and translated this thread with Ai:

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.