General question regarding support period of distros (Ubuntu and derivatives)

Ubuntu
1

Hi all, :wave:

I´m still not quite sure about the support philosophy of certain distros. :thinking:
I´m talking about the fixed release model here, so not rolling releases or semi-rolling ones.
In the following I put the focus on Ubuntu and derivatives.

Inspired by a previous discussion (Question regarding /etc/apt/sources.list and support period - #28 by Rosika )
I am still wondering how different Ubuntu repositories (and those for derivatives) provide updates for packages.

I´ve been doing some research on the matter but essentially could come up with only a few minimum facts:

  • Ubuntu and the other derivates all seem to use the same repositories.
  • The only difference: Server and “normal” Ubuntu only use packages from the “main” and “restricted” branches, which are supported by Canonical for 5 years.
  • All other derivatives come with packages from “universe” and even “multiverse”.
  • By default, “universe” and “multiverse” are not active in Server.

Hmm … :thinking:

I know that e.g. Lubuntu offers just 3 ys of support, but here there are “main”, “restricted”, “universe” and “multiverse” set as active, which makes the situation clear, I think. All in all: 3 ys. of support. :wink:

Another statement I found somewhere was:

So if you use Ubuntu [i.e. Ubuntu proper] and don’t install a single package from “universe” or “multiverse”, you have 5 years of support. Otherwise only 3 years.

I think I understand it on a general level, but I also found the information that the majority of packages (particularly those post-installed by the user) are from “universe”.

If that really is true … I cannot see why Ubuntu proper should be regarded as a distro which receives 5 ys. of support. :face_with_diagonal_mouth:

I mean: is there any realistic scenario of a user avoiding packages from “universe” completely on Ubuntu :question:
Cos´ that would be the prerequisite for 5 ys, support, right?

Thanks a lot in advance for your help and opinions.

Many greetings from Rosika :slightly_smiling_face:

2

I don’t know precisely how Ubuntu makes it all work, but in general it’s less about repositories and more about versions.

If there is a repository, with packages that all have versions according to what Ubuntu 22.04 expects, then this version of the repository is the one getting 5 years of LTS.

If I understand correctly, the “universe” and other repositories have not that important packages. So, it may be the case that those repositories aren’t as watched after and supported, as the core repositories.

The core repositories however, contain the most important packages, which gain the biggest support effort.

That said, it’s common for Ubuntu users to put all “support” into a single pot and just call it “support”. That is not true, though. There are several levels of support.

Hardcore “I don’t want to upgrade ever” users, possibly look at this graph and say that Ubuntu 22.04 is supported until 2032. However, the support starts being maintenance only 2026, which means that after 2026 the only “support” that will be available are backported security fixes, that’s it. Nothing more. That’s the bare minimum support, that you can get.

Therefore, “support” is not always support. Which is why it wouldn’t surprise me that you only get 3 years of support for not that important packages, while the core packages are guaranteed to receive 5 years of support.

2 Likes
3

Hi @Akito,

thanks once more for your very detailed answer. :heart:

I found a pretty good article dealing with the topic here: https://www.howtogeek.com/194247/whats-the-difference-between-main-restricted-universe-and-multiverse-on-ubuntu/ and came across this statement which made me scratch my head: :pensive:

The vast majority of the software in the Ubuntu Software Center comes from the Universe repository.
These packages are either automatically imported from the latest version of Debian or uploaded and maintained by the Ubuntu community.

So the author is talking about the “vast majority of the software in the Ubuntu Software Center”…
Therefore my thinking: how then can Ubuntu state it receives 5 ys of support… :question:
That would account for “Main” and “Restricted” only.

Again: “vast majority of software”… is in “universe”.

But you´re right, of course:

Canonical does not provide official support or updates for these packages.
An Ubuntu LTS release might be supported for five years, but the packages in the Universe repository aren’t officially supported at all.
They’re generally fine, but they’re not guaranteed to receive security updates.
If a security update is found, these packages may never receive it until the next release of Ubuntu when a newer version of the package is automatically pulled in.

(source from above)

Thanks @Akito for the link regarding Ubuntu lifecycle. I´ll look into it.

The background of my question is the following:

I´ve been using Lubuntu since I switched over to a Linux-based distro as my daily driver in mid 2016.
It´s a great system for my purposes and indeed a resource-friendly distro is very much appreciated in my case.

The only thing which is a bit cumbersome to me is I have to do a fresh/clean install every two years (if I do it regularly).

Therefore I was wondering: should I give Ubuntu or (even better:) LinuxLite a try?
LinuxLite also states it receives 5 ys of support and it´s based on Ubuntu LTS.
So I´d have to do a fresh install just every 4 years. :thinking:

BUT:

If there´s no real 5-years-support either in Ubuntu or in LinuxLite (due to installation of “universe” packages) I might as well stay with Lubuntu… :smiley:

Thanks a lot for your help.

Many greetings from Rosika :slightly_smiling_face:

4

Because, there are tons of programs that you won’t ever need or use.

There are levels of “importance” in a distribution. The most important core packages are the ones that are absolutely necessary to keep the system running. These are maintained by Canonical (Ubuntu) and receive the guaranteed 5 years of support.

The “vast majority of software” is the “optional” software from a variety of maintainers (Ubuntu community). How much these packages are supported is, to my knowledge, entirely up to the developers. Though, this also means, it does not relate to LTS in the first place, because it’s not up to Canonical (Ubuntu) how much or long they are supported. At least, I am not aware of a contract that developers have to sign regarding minimum support terms.

If “universe” is for all developers not directly affiliated with Canonical (Ubuntu), then the things I said in the previous paragraph most likely apply here. It’s all up to the vast majority of individual developers, how much their software is supported and for how long. It’s not related to LTS, at all.

That’s what I am talking about. The core packages (the most important ones) are released and maintained by Canonical (Ubuntu). These are the ones getting LTS. However, third party software from third party maintainers do not abide these rules. It’s a bit like on Github. Either the software is maintained or not. They do not sign a contract stating, that they need to provide LTS, in any way, as far as I know.

No, I think this is a purely theoretical assessment and does not apply to reality. For example, there are tons of reasons why you would still apply an upgrade or fresh install more frequently. For example, you need the newest version of a software, but the dependencies the old Ubuntu operating system provides, are too old.
Or, something happens and you have to do a fresh install anyway, because you need that one thing and restoring a backup does not fix it, since you still need that one modificaiton.
It’s also usually better and more secure to upgrade more frequently.

Still not sure, why you are forced to do a fresh install, instead of doing proper upgrades, however if that is such an issue for you, I would instead recommend that you automate the fresh installation so much, that it would take just a bit of effort to do a fresh install. This way, you can do it very frequently, but with the pain minimised.

There are also projects available, that are working on doing something like this pretty easily.

Again, I think this is not the right question. It’s really not that important. It’s better either way to just upgrade more frequently.

That said, it is real 5 year support, but only for packages Canonical (Ubuntu) provides and maintains. So, it is real. It’s just that the core packages are just a small subset of the total packages available.

1 Like
5

Hi again @Akito, :wave:
and thanks for putting so much time and effort into helping me getting things sorted out. :heart:

O.K., I get that. On the ubuntu_release-cycle you provided they say:

The debs in Ubuntu are categorised by whether they are considered part of the base system (‘main’ and ‘restricted’ are in the base and ‘universe’ and ‘multiverse’ are not)

These are the most impiortant packages that get 5 ys support then.

Hmm, :thinking:
As Lubuntu LTS is based on Ubuntu LTS this should (hopefully) be true for Lubuntu as well then.

So I guess the real difference between Ubuntu and a derivative (in my case Lubuntu) is that Lubuntu makes more (or extended) use of packages located in “universe” per default and thus claims it´s supported for 3 years…

So the Lubuntu-community-maintained packages are here / in “universe”.

Yes, right.
Therefore my initial question

I simply cannot believe that a Ubuntu user can go along with his/her setup without ever having to install something from “universe”…

And for those packages he/she doesn´t get 5 ys of support.

From that it would follow: I may very well stay with Lubuntu as Ubuntu or LinuxLite won´t have 5 ys support for EVERY package either. :face_with_raised_eyebrow:

With proper upgrades do you mean those in-place-upgrades which I can iniitiate from a running system?

I´ve never done that before as experts say this method would be more error-prone than a nuke-and-pave approach and thus it´s more risky.
I´ve never had the courage to try it. :blush:

No, actually not a big issue per se. I was just wondering whether there would be a way of not having to reinstall every two years.
However I thingk the more often I do it the more I might get accustomed to it. :smiley:

But thanks a lot for goldboot link. I´ll look into it as well.

Yes, thanks for stating that so clearly. So I´ll stick to that golden rule.

I think I got it all now. Thanks again for your kind help @Akito.

Many greetings from Rosika :slightly_smiling_face:

6

No, that’s not the point. The point is that the most important packages are so important, that they are required for the operating system to function, so they absolutely need to work. On the other hand, if some of the optional packages from the “universe” repository break, it’s not as big of a deal.

So, if the most important packages have LTS, then that’s more or less “enough” for what it’s worth.

It is more error prone, however you mentioned how annoying the fresh installs are, so I mentioned an easier but perhaps more error prone alternative.

You have so many backups and use VMs all the time, you have all the possibilities to easily try.

1 Like
7

Thanks again, @Akito :wave:

Yes, you´re perfectly right of course.

I was just wondering whether the blunt distinction
Ubuntu: 5ys / Lubuntu: 3 ys
would be unambiguously correct. Seems it´s not so clear.

ubuntu-security-status on my system states the following:


ubuntu-security-status
2789 packages installed, of which:
1801 receive package updates with LTS until 4/2025
[...]

So those 1801 packages seem to belong to the base part (“main”).
The rest would probably be from “universe”…

Well, yes, but rather time-consuming than annoying. :wink:

… and I thank you for doing so. It´s highly appreciated. :+1:

Thanks again. You´re too kind @Akito

Many greetings
Rosika :slightly_smiling_face:

8

Yes, though, as I mentioned previously, It does not really matter that much. It would matter if you would host an important server for a community, but if you just run your own Ubuntu, then I’m convinced it’s not a big issue.

Yes, security relevant packages are pretty much always part of the core system, because they are, obviously, absolutely critical. For example, a bug in the SSL library could be absolutely fatal and could cost organisations millions of bucks in damages.

Another reason, to automate it. :wink:

1 Like
9

Rosika and Akito: while I enjoyed your discussion and feel much more that I understand the issues than before, I have to ask ‘what’s the difference?’ I maintain my necessary data–contacts, pictures, music, Robin Williams on ‘Golf’ on a separate hard drive (duplicated on my NAS). All of my internet data–bookmarks, essentially–live in my Firefox account.

My computer could blow up at any second, or a grandchild could misuse the format command and I’d be looking at a blank screen. All I have to do is plug in one of a dozen USB sticks, install any one of a hundred isos, and I’m back in business in minutes. Fresh installs are a daily occurrence for me; updates and upgrades are there, but just as an annoyance.

I abandoned Windows and IOS to get away from the issues you were discussing. Don’t miss it much.

2 Likes
10

Hi @Rosika ,
There is a third alternarive to fresh install versus inplace upgrade.
Do you have space on your disk to install a new linux alongside the current linux?
That would make it a multiboot computer with 2 linuxes

It has advantages… you can take your time getting used to the new linux, setting up all your configurations, and transferring your home directory. Then when you are totally happy with the new linux, you can erase the old one. I used to do my Debian upgrades this way, but recently I took the risk and did an inplace upgrade.

If you dont have the disk space, it might be worth looking into getting another disk. They are not expensive.

Regards
Neville

1 Like
11

Hi again to all of you, :wave:

thank you so much for your latest input.

@Akito:

Yes, I see what you mean.

Well, to me it seems, it really doesn´t matter that much.
As the ubuntu-security-status revealed those 1801 core-packages in “main” are supplied with security updates until 4/2025.
In this regard there´s basically no difference to Ubuntu itself.

As for packages in “universe”: I would need to do a fresh install or upgrade in both cases because even on Ubuntu I´d surely have something installed from “universe”… :expressionless:

So I really can´t see any benefit for giving up Lubuntu in favour of Ubuntu (especially in view of the fact that I need a resource-friendly distro). :wink:

Quite.
I´ve taken look at goldboot in the meantime but have to invest more time and effort.
Can´t say I understood how it works… :frowning_face:

I´ll keep trying though.

@berninghausen:

Sounds likea good plan for you, Bill. :slightly_smiling_face:

As I´m not a pro like you, Bill, I do it this way:

I have 3 partitions: root, home and data-partition.
When doing a fresh install I format root and home but leave the third one untouched.
For backaups I do a clonezilla disk-backup (covers everything) once a month. Plus: once a week I let timeshift do its work… :wink:

Of course your setup is much more professional.

@nevj:

Thanks, Neville, for bringing up a third method. Sounds interesting.

Well, yes. I employ a 1 TB external HDD for my setup. My current Lubuntu occupies 273 GB (all 3 partitions). So I´ve still got 727 GB left.

Hmm, I´ve got Lubuntu 20.04 LTS now. If I wanted to stick with Lubuntu … I´d have to install Lubuntu 22.04 LTS for that matter.
I´m just wondering: would that be doable?
Two times Lubuntu.
Wouldn´t that trigger some issues in Grub :question:
It may well be a silly question. But better safe than sorry. :wink:

Thans so much to all of you for your help. :heart:

Many greetings from Rosika :slightly_smiling_face:

12

Goldboot isn’t quite ready yet, anyway.

I would suggest, you start making a plan of all configuration, packages, etc. you need and then write a couple of simple shell scripts, doing what you want.

1 Like
13

Not a reply to the main question but i would like to share. I did 2 Ubuntu LTS upgrades so far (16-18 & 18-20) and i will upgrade to 22 soon (whenever they publish the point release). Every time I prepared myself for the worst but it went pretty straightforward so far. Maybe the experience is not the same for derivatives like Lubuntu…

1 Like
14

Not a problem. I have 2 almost identical versions of Void at the moment. Grub labels them by the partition label, so I can tell which is which. Two linuxes on separate partitions can not interact, because only one is running at any time.

You have plenty of space. You only need one swap partition, the two linuxes can share it.

That is the answer for you, because it takes all the trauma out of the upgrade. You can do things gracefully , in your own time, because the old distro is there as a fallback.

One distro has to control grub… ie house the grub.cfg file. You can choose which… I would choose the new linux as the grub controller.

Regards
Neville

1 Like
15

Hi again, :wave:

@Akito:

Yes, that´s the plan I´ve employed so far (aside from writing some shell scripts).
All necessary steps reside in my text file “Reihenfolge_Vorbereitungen_zum_System-Upgrade” i.e. Sequence_preparations_for_system_upgrade.

It served me well during the two fresh installs I had to do until now. :wink:

Thanks a lot.

@ahmetbombaci:

Hi Ahmet,

That´s great. :+1:

According to https://manual.lubuntu.me/stable/D/upgrading.html , which gives some detailed instructions for upgrading, it can be done.

The situation was different when Lubuntu decided to go from LXDE to LXQt. Back then an upgrade was not possible.

Thans so much.

@nevj:

Thanks, Neville, for the explanation.

O.K. That´s clear to me , I think.

Thanks for pointing that out, Neville.

But I´m a bit confused now. Sorry. :frowning_face:

Let´s say I have Lubuntu 20.04 and 22.04 installed.
Then there are 5 partitions in use: root and home for 20.04 and root and home for 22.04 and my third (data) partition (which should be used for both Lubuntus).

Right now with only Lubuntu 20.04 installed there´s:

/boot/grub/grub.cfg

I guess an additional Lubuntu (22.04) would have it as well.

So how should I proceed? Should the grub.cfg file in /boot/grub/grub.cfg be deleted from Lubuntu 20.04 then :question:

Sorry for my asking.

Thanks a lot .

Many greetings
Rosika :slightly_smiling_face:

1 Like
16

@Rosika
Grub does not really care about Linux versions, Grub will detect the partition that Linux is installed on
and it will displayed in your Grub menu. That is why you run grub-update in the Linux you wish to use.
OS_PROBER can be disabled in your old Linux install and enabled in your new Linux install, you will
then have no conflict as to which Linux is booting first.
Of course the best way to deploy two Linux, is to use two different drives and set your bios to the drive
you wish to boot first. I have Manjaro, W8 and Gentoo running on one of my PC, but the
Manjaro drive boots first, and Manjaro grub finds the other entry’s.

17

No you dont need to delete grub.cfg from the old linux.

Just these steps

  • do a backup (I dont need to tell you that)
  • make partitions for new linux root and home filesystems
  • install the new linux on these partitions. Tell it to use the existing swap space. Tell it to install grub… ie you want to overwrite the current grub with the new one… that will link grub to the new linux.
  • reboot after install, and it should bring up a grub menu with the new linux only… so boot into that
  • from within the new linux do update-grub ,… it should find both linuxes. … if it gives a message about os-prober and doesnt find the old linux, you need to enable os-prober by going into /etc/default/grub and setting OS-PROBER-DISABLE=false… (I think thats right, i need to check) Then redo update-grub and it should find both linuxes
  • reboot and you should get a grub menu with both linuxes displayed.

That will give grub control to the new linux

If you want the old linux to control grub.

  • tell the new linux not to install a bootloader during the install
  • when the install finishes, reboot and you should get the old linux
  • in the old linux do update-grub… . do the same as above if it cant find os-prober.
  • when you get update-grub to work, reboot and you should get a grub
    menu with both linuxes.

Sounds a lot, but its really very easy.
Someone with your skills should have no trouble

Regards
Neville

Correction
One workaround (for now) is to add GRUB_DISABLE_OS_PROBER=false to /etc/default/grub

I did not get that quite right, sorry.

2 Likes
18

@nevj
Your explanation is very good, and while Grub will overwrite, with the new Linux install, I would most
surely disable OS_PROBER in the old Linux before I installed the new Linux. This would keep the old
Linux from displaying a full Grub menu when booting.

1 Like
19

I think it depends whether @Rosika wants the old or the new linux to control grub?
Lets sit on that. It can be fixed after anyway.
It is a fairly simple job to just drop a new linux onto a new partition. The only issue is getting grub to see both linuxes. I think @Rosika can cope with that, she is very thorough and systematic.

20

@nevj
OK, The new Linux is going to overwrite Grub. The boot order in Grub can also be set by the
GRUB_DEFAULT=0 to the #of the old Linux install in the Grub menu, without invoking the
OS_PROBER. Just make sure and use 0 as the first # when counting .

1 Like