Re: debian kernel pickup startegy vs linux LTS kernels
On 06/08/2023 00:08, Hans van Kranenburg wrote:
Hi Eric,
I think I can help answering this one. It's a good question.
Thanks for taking the time to answer and sorry for this mailing list
polution but debian-kernel-maint mailing list is long dead.
On 8/5/23 10:43, Eric Valette wrote:
Hi Debian kernel maintainers,
I have a question regarding the way kernel versions are selected for the
stable tree. [...]
[...]
Two days ago, I was a bit surprised to see that only 6.1.38-2 was pushed
to correct zenbleed while at least 6.1.41 was available for a week or so
and we are now at 6.1.43.
So my questions are:
- Why did you not pick up the last LTS version?
The 6.1.38-2 package version is a security update. It has two extra
included patches compared to the previous 6.1.38-1.
But even 38 was quite old at that time (did not check exactly but...)
https://tracker.debian.org/news/1449038/accepted-linux-6138-2-source-into-stable-security/
When preparing a security update, first an attempt is made to provide a
new package containing the needed fixes, and at the same time having the
least possible amount of other changes included. In this case, it seems
this was possible, by just picking two new upstream changes, still on
top of the source version 6.1.38.
Sure. I understand the need for a "as fast as possible" security fix as
well as the least risk of breaking something while taking a larger patch
that include the needed code but also other modifications.
- On what occasion do you pick up a new LTS kernel for the
stable branch? Is there any formal rule?
For regular Debian stable point releases, which tend to happen about
every two months, there usually will be a package update that follows
the stable upstream branch. At that point, the upstream source will be
updated to whatever is current upstream (LTS) stable version, and the
separately added security patches can be dropped again.
Okay clear. So the LTS kernel is updated on regular basis but not driven
by upstream update but by debian point release. Correct?
The security updates happen 'in between' the normal point releases, and
by trying to keep them as small as possible, we also might for example
accommodate users who treat installing a security update differently
than a stable point release.
Understood.
Extra...1!
After a security update is published, it also automatically gets queued
for stable-proposed-updates (for the next official point release). At
https://tracker.debian.org/pkg/linux this is visible at 2023-07-31,
where it happens a day later:
https://tracker.debian.org/news/1449227/accepted-linux-6138-2-source-into-proposed-updates/
So, even if for some reason there would not be a separate update for the
point release, the earlier security update will then be the version that
gets included.
OK.
Extra...2!
In some exceptional situations, it might be desirable to already provide
a new package with a new upstream (LTS/stable) kernel version, for
reasons that do not warrant doing a security update. For example, there
might be some non-trivial regression bugs that hit a bunch of users with
specific use cases / hardware. If downgrading to the previous package
version as workaround is also not an option because of some serious
other problem, the kernel team might decide to do some extra work
already to help those users get out of the uncomfortable situation right
now. (These should be exceptional ;])
Personnal feeling: when reporting such a bug/regression (I sometime
follow some of this mailing list specific bug) provided answer usually
requires to do a bisect if the bug appears in the new LTS stable
*Debian* kernel and try newer non LTS kernel from unstable/experimental.
The user (whith help from maintainer) has to find by istelf if the bug
is known upstream, fixed and backported. If the debian stable LTS kernel
is behind the upstream last LTS for several releases as actually, this
is frustrating and requires extra work to test the last upstream LTS.
In that case, the kernel team can already do similar work as would
otherwise be done later (closer to the Debian stable point release
date), and for example already upload a package with new upstream source
version. In that case, it also gets uploaded to stable-proposed-update,
and users who really want or need it, can install it from there.
It's officially signed (the package repository) and at least the users
do not need to build it themselves etc.
Sure not everyone has the knowledge to do this.
No criticism just curious : I can always pick up the Debian kernel, the
Debian config, slightly modify it for the kernel signature and sign the
produced kernel and modules. Just that given the handful of modules I do
not need, this is time consuming and I find myself out of normal Debian
path.
Thanks, have fun!
Thanks for the detailled answer.
Regards,
--eric
Reply to: