Debian Developers - Getting newer kernels into stable

Author

Getting newer kernels into stable

Andrew Pollock

2004-03-28, 9:35 pm

Hi,

I'd like to start a discussion on the ins and outs of getting newer kernels
into stable.

This is provoked by Chris' email, msgid <20040329002543.GP9248@cheney.cx>

I realise there are issues with adding and removing kernels into stable, as
the security maintenance goes up, and I'd like to hear what the security
team has to say about that. Or perhaps newer kernels should go into
stable-proposed-updates? This doesn't really address the installation issues
that people have with newer hardware though.

Is it feasable for subsequent point releases of stable to ship with newer
kernels by default, and security support for earlier kernels to be
discontinued at point release time?

for example, let's say hypothetically, Sarge shipped with 2.6.4, and then 3
months later, Sarge_r1 ships with 2.6.6 as the default kernel, and a month
later, a vulnerability is found in 2.6.4, that isn't in 2.6.6. Would we need
to issue a patched 2.6.4 if we were already providing a non-vulnerable 2.6.6
in a newer point release of stable?

I think the kernel is probably the single biggest package that really dates
a stable release (sure, there's lots of other "perishable" packages like
spamassassin and snort, for example), but if you can't install the stable
release because the kernel it uses can't find your hardware, then you're
really behind the eightball from the word go.

Joey, as SRM, what do you think? Is the installability of stable releases on
modern hardware something you think is significant? Is there some sort of
compromise that can be arrived at for the handling of newer kernels in
stable?

regards

Andrew

Henning Makholm

2004-03-28, 11:36 pm

Scripsit Andrew Pollock <debian-lists-2004@andrew.net.au>

> for example, let's say hypothetically, Sarge shipped with 2.6.4, and then 3
> months later, Sarge_r1 ships with 2.6.6 as the default kernel, and a month
> later, a vulnerability is found in 2.6.4, that isn't in 2.6.6. Would we need
> to issue a patched 2.6.4 if we were already providing a non-vulnerable 2.6.6
> in a newer point release of stable?

If a patched 2.6.4 were *not* released, people would not be able to get
the patch simply by doing 'apt-get update && apt-get upgrade' once in
a while.

Even if we issued an empty transition kernel-image-2.6.4 to pull in
2.6.6 (which is dangerous in and of itself), apt-get would not
actually upgrade unless it gets 'apt-get dist-upgrade'.

--
Henning Makholm "En tapper tinsoldat. En dame i
spagat. Du er en lykkelig mand ..."

--
To UNSUBSCRIBE, email to debian-devel-request@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org

Andrew Pollock

2004-03-29, 1:35 am

On Mon, Mar 29, 2004 at 04:14:16AM +0100, Henning Makholm wrote:
> Scripsit Andrew Pollock <debian-lists-2004@andrew.net.au>
>
>
> If a patched 2.6.4 were *not* released, people would not be able to get
> the patch simply by doing 'apt-get update && apt-get upgrade' once in
> a while.
>
> Even if we issued an empty transition kernel-image-2.6.4 to pull in
> 2.6.6 (which is dangerous in and of itself), apt-get would not
> actually upgrade unless it gets 'apt-get dist-upgrade'.

I understand where you're coming from.

However, if a newly installed stable system installed the kernel-image-2.6
virtual package, an apt-get upgrade would upgrade the kernel if this virtual
package subsequently depended on kernel-image-2.6.6 instead of
kernel-image-2.6.4 (which is another spin on what you're saying above,
anyway).

regards

Andrew

--
To UNSUBSCRIBE, email to debian-devel-request@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org

Bernd Eckenfels

2004-03-29, 1:35 am

On Mon, Mar 29, 2004 at 03:33:12PM +1000, Andrew Pollock wrote:
> However, if a newly installed stable system installed the kernel-image-2.6
> virtual package, an apt-get upgrade would upgrade the kernel if this virtual
> package subsequently depended on kernel-image-2.6.6 instead of
> kernel-image-2.6.4 (which is another spin on what you're saying above,
> anyway).

Perhaps it is a good idea to have a distribution specific default kernel
virtual package, maybe for different streams, but preferrrable not.

linux-image-woody-i386

or

linux-image-woody-i386-2.4

Where we gurantee updates as long as the distribution is supported. I am not
sure if it makes sence, since we have quite a few kernel package flavours.

Greetings
Bernd
--
(OO) -- Bernd_Eckenfels@Mörscher_Strasse_8.76185Karlsruhe.de --
( .. ) ecki@{inka.de,linux.de,debian.org} http://www.eckes.org/
o--o 1024D/E383CD7E eckes@IRCNet v:+497211603874 f:+497211603875
(O____O) When cryptography is outlawed, bayl bhgynjf jvyy unir cevinpl!

--
To UNSUBSCRIBE, email to debian-devel-request@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org

Henning Makholm

2004-03-29, 6:37 pm

Scripsit Andrew Pollock <debian-lists-2004@andrew.net.au>
> On Mon, Mar 29, 2004 at 04:14:16AM +0100, Henning Makholm wrote:

[color=darkred]
> However, if a newly installed stable system installed the kernel-image-2.6
> virtual package, an apt-get upgrade would upgrade the kernel if this virtual
> package subsequently depended on kernel-image-2.6.6 instead of
> kernel-image-2.6.4 (which is another spin on what you're saying above,
> anyway).

(Hm, this makes more sense if you mean "meta-package" rather than
"virtual package, right?)

Is this some new magic capability of apt-get? What exactly triggers
it? I thought that the distinction between ordinary packages and
meta-packages was just in the heads of the developer and user (and
also in the long description), but not actually known to any of the
package-management tools.

My own experience is that 'apt-get upgrade' will just refrain from
upgrading a package if the new version depends on a package that is
not already installed on the system.

--
Henning Makholm "We can hope that this serious deficiency will be
remedied in the final version of BibTeX, 1.0, which is
expected to appear when the LaTeX 3.0 development is completed."

--
To UNSUBSCRIBE, email to debian-devel-request@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org

Andrew Pollock

2004-03-31, 7:37 am

On Mon, Mar 29, 2004 at 11:59:05PM +0100, Henning Makholm wrote:
> Scripsit Andrew Pollock <debian-lists-2004@andrew.net.au>
>
>
>
> (Hm, this makes more sense if you mean "meta-package" rather than
> "virtual package, right?)

Probably.

> Is this some new magic capability of apt-get? What exactly triggers
> it? I thought that the distinction between ordinary packages and
> meta-packages was just in the heads of the developer and user (and
> also in the long description), but not actually known to any of the
> package-management tools.

See the kernel-image-2.4-686 package (for example).

regards

Andrew

--
To UNSUBSCRIBE, email to debian-devel-request@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org

Henning Makholm

2004-03-31, 7:38 am

Scripsit Andrew Pollock
> On Mon, Mar 29, 2004 at 11:59:05PM +0100, Henning Makholm wrote:

[color=darkred]
> See the kernel-image-2.4-686 package (for example).

Its control file looks perfectly ordinary. Which feature in it
triggers the non-standard apt behavior you claim to exist?

--
Henning Makholm Science, by its nature, is an uncertain undertaking, and
offers plenty of opportunity for failure no matter how you
approach it. Yet among the myriad ways to get nowhere, the only
fully reliable one is doing and thinking the same as everyone else.

--
To UNSUBSCRIBE, email to debian-devel-request@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org

Andrew Pollock

2004-04-02, 6:37 pm

On Wed, Mar 31, 2004 at 01:06:29PM +0100, Henning Makholm wrote:
> Scripsit Andrew Pollock
>
>
>
> Its control file looks perfectly ordinary. Which feature in it
> triggers the non-standard apt behavior you claim to exist?

I think what happens is when there's a new kernel, a new version of this
package is also uploaded with a control file that references the newer
kernel package.

regards

Andrew

--
To UNSUBSCRIBE, email to debian-devel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org

Henning Makholm

2004-04-02, 7:34 pm

Scripsit Andrew Pollock <debian-lists-2004@andrew.net.au>
> On Wed, Mar 31, 2004 at 01:06:29PM +0100, Henning Makholm wrote:

[color=darkred]
> I think what happens is when there's a new kernel, a new version of this
> package is also uploaded with a control file that references the newer
> kernel package.

As I have already explained, that will *not* make 'apt-get upgrade'
install the newer kernel package automatically. RTFM, please:

upgrade is used to install the newest versions of all packages
currently installed on the system from the sources enumerated in
/etc/apt/sources.list. Packages currently installed with new
versions available are retrieved and upgraded; UNDER NO
CIRCUMSTANCES are currently installed packages removed, or
PACKAGES NOT ALREADY INSTALLED retrieved and installed. ...

My emphasis. Which part of "under no circumstances" does one of us not
understand?

--
Henning Makholm "Anything you can discover we
would be most happy to review."

--
To UNSUBSCRIBE, email to debian-devel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org

Martin Schulze

2004-04-05, 4:34 am

Andrew Pollock wrote:
> I realise there are issues with adding and removing kernels into stable, as
> the security maintenance goes up, and I'd like to hear what the security
> team has to say about that. Or perhaps newer kernels should go into
> stable-proposed-updates? This doesn't really address the installation issues
> that people have with newer hardware though.

New kernels for stable are a no-go except for very few exceptions.

If you want to provide updated kernel packages for Debian stable,
that's fine and I appreciate it, but please create a repository on
<http://people.debian.org/~apollock/kernel/> or similar.

Updating kernel images in Debian stable affects more than we may think
about in the first place, such as:

. tons of modules packages that would have to be updated as well

. tons of patch packages that won't work with newer kernels

. modules packages won't work with a modified ABI

. additional kernel packages hurt the security team support-wise

. additional kernel packages break debian-cd creation

. new kernel packages imply that old packages have to go

. new kernel packages can introduce new cans of worms

. potential problems with the installer

Hence, I am not convinced at all that new kernel packages are suited
for Debian stable. However I would love somebody to maintain a
repository of (security fixed, of course) kernels for Debian stable so
those users who would like to use them, are free to do so. Such a
location should be documented in the Release Notes.

> Is it feasable for subsequent point releases of stable to ship with newer
> kernels by default, and security support for earlier kernels to be
> discontinued at point release time?

Please explain the "by default" part. For woody/i386 one default is
2.2.22 and another default is 2.4.18, whereas the default is installed
from boot-floppies and not from kernel-image packages.

> for example, let's say hypothetically, Sarge shipped with 2.6.4, and then 3
> months later, Sarge_r1 ships with 2.6.6 as the default kernel, and a month
> later, a vulnerability is found in 2.6.4, that isn't in 2.6.6. Would we need
> to issue a patched 2.6.4 if we were already providing a non-vulnerable 2.6.6
> in a newer point release of stable?

Yes.

> I think the kernel is probably the single biggest package that really dates
> a stable release (sure, there's lots of other "perishable" packages like
> spamassassin and snort, for example), but if you can't install the stable
> release because the kernel it uses can't find your hardware, then you're
> really behind the eightball from the word go.

If you can't insatll the stable release because the kernel was updated
and the new version doesn't work as expected, you're doomed as well.

As I stated above, I'd love to see a repository of updated packages,
just keep them aside but visible.

> Joey, as SRM, what do you think? Is the installability of stable releases on
> modern hardware something you think is significant? Is there some sort of
> compromise that can be arrived at for the handling of newer kernels in
> stable?

It is significant, but updating the kernel is still not the path to take.

Regards,

Joey

--
A mathematician is a machine for converting coffee into theorems. Paul Erdös

Please always Cc to me when replying to me on the lists.

--
To UNSUBSCRIBE, email to debian-devel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org