Re: a kernel plan for sarge and beyond ... (Was Re: ABI-changing kernel security fixes for sarge)
On Thu, 24 Mar 2005 17:02:29 -0800, Steve Langasek wrote:
> On Thu, Mar 24, 2005 at 03:30:01PM -0500, Andres Salomon wrote:
>> (ignoring -release followup-to, since it affects -kernel and -boot as well)
>
> Sorry, mailer misfire, I guess.
>
>> On Thu, 24 Mar 2005 03:24:53 -0800, Steve Langasek wrote:
>
>> > recompiles on every revision of a kernel-image package, which is slightly
>> > irritating; or failing to provide a smooth downgrade path in the event of an
>
>> That is irritating, but less so than rebooting and discovering you need to
>> run `module-assistant auto-install <foo>` to compile a module for an ABI
>> change (and if the machine requires the third party module to boot and get
>> online, fun ensues). That said, if we could get a solution to long NEW
>> processing times, then doing both in tandem (ABINAMEs + recompile hooks
>> upon ABI and major kernel upgrades) is a possibility.
>
> I don't believe long NEW processing times are seriously an issue here; the
> ftp team is very responsive to needs for quick processing of
> release-relevant kernel packages. The problem, AFAICT, is that it currently
> takes so many *iterations* of NEW processing to get everything updated for a
> kernel ABI change, including kernel-image packages for 11 architectures that
> arrive in NEW over a span of weeks, plus whatever module binary packages
> there are.
>
Release-relevant kernels are not the only kernels we (the kernel team)
care about. I uploaded kernel-image-2.6.10-sparc a week ago. For a
normal package, a long wait is fine (I have ruby libraries that have been
in NEW for 2 months, but I'm not in any sort of rush). However, for
kernel updates, a long wait is not fine. New kernels fix numerous bugs,
security holes, etc. By leaving them rotting in NEW, we do a disservice
to our users using unstable. And, quite frankly, it's annoying having to
*constantly* work around NEW. "Oh, well, let's fix this and this, and
not this; build and upload; then fix this other thing, bump the ABINAME,
and upload." I have come to despise NEW, since joining the kernel team.
>> > ABI change that coincides with a silently broken module, which is
>> > truly ugly. The idea of automatically recompiling modules sounds
>> > good to me, but I still think it needs to be coupled with kernel ABI
>> > tracking to avoid the risk of slagging the user's initrd.
>
>> How would the initrd get slagged? It would need to be regenerated, of
>> course, during the upgrade to pull in newly built modules.
>
> Any time you rebuild your kernel binary modules, there's a non-zero
> chance that the rebuilt version will not work correctly even though it
> built successfully. If you aren't going to track ABI changes, then you
> have no backup kernel to use in this case (because you've overwritten
> the old one with a binary-incompatible one) that would let you roll back
> the change in the event that one of the modules that broke rendered your
> system unbootable.
Non-ABI changing upgrades don't allow this anyways, and they're the most
common scenario. I've never seen an i386 kernel's ABINAME go past -2.
Older kernels would still function perfectly well as backup kernels, as
well. If something in 2.6.11 breaks during an upgrade, boot into 2.6.10
and fix it.
>
> It's a standard part of my system administration practices to keep a
> previous kernel version around that I can roll back to when upgrading to
> a new version; this approach would seem to make that more awkward.
I'd argue that our current practice of tracking ABIs has done more damage,
by allowing ABI changes to slip through, breaking already built modules,
as well as assuming the user wants to boot into the latest kernel without
handling their third party modules automatically.
Reply to: