Re: a kernel plan for sarge and beyond ... (Was Re: ABI-changing kernel security fixes for sarge)
On Thu, 24 Mar 2005 09:24:48 +0100, Sven Luther wrote:
[...]
> The proposal is the following :
>
> 1) now that rc3 is out we forget about the current kernels, well, not
> exactly, but we forget about the current kernel build system,
> including .udebs.
>
> 2) we take as basis the ubuntu kernel build infrastructure.
>
> 3) we throw out the ubuntu patches, configs and 2.6.10 orig source
> tarball.
>
Basing post-sarge kernels off the ubuntu kernel build infrastructure is
something we've planned for a while. Are you saying do this for 2.6.8 as
well? I'm not overly excited about doing more work on 2.6.8; I'd rather
see sarge release. If it doesn't release, then let's pull 2.6.12 or
whatever in (w/ whatever build infrastructure changes we might've made to
it. No sense holding back progress in the sid kernels because sarge is
taking forever).
> 4) we add our (2.4.27/2.6.8) own patches, and the kernel configs for
> all our arches.
>
One of the things that both ubuntu and debian need is a config tool to
make configs consistent across all archs. I started on this, but never
finished it; I'll finish it at some point, but there are higher priority
things to do right now.
> 5) we add support for the series patch handling support which is
> superior to the ubuntu one.
>
While I agree that the series stuff is, the kernel-tree stuff shouldn't be
necessary w/ a single-source kernel-source package. When a new upload is
done, the buildds for all archs should rebuild kernel images; no mess, no
fuss, no need to keep support for kernel-image packages that explicitly
build against an older kernel-source patchset. Of course, we won't be
able to do this immediately; not until all archs are generated from
kernel-source.
> 6) we add support for per-arch/subarch patchsets, which is needed for
> replacing the current kernels.
>
Ype.
> 7) we (well, probably joey and colin), adapt the .udeb generation to
> generate those .udebs directly from the kernel packages as ubuntu
> does. We need to keep our current working rc3 module list though.
>
I'm not sold on the udeb generation stuff, but I haven't looked into it
that much. If you, joeyh, and the rest of the d-i people think it's a
good idea, then I don't see a reason not to. I haven't heard the opinions
of the rest of the d-i people, other than someone mentioning something
about breaking dpkg due to the sheer number of generated binary packages.
I dunno if that's still the case.
> Once we have that, which can be done concurently with the remaining of
> sarge release process, we are in a good shape to launch a final rebuild
> of the d-i images with those kernels, and we will have an infrastructure
> which will allow streamlined new d-i uploads in a couple of says, even
> with kernel abi changes, since it would only need :
>
> A) fix the only kernel-source's security issue, check that it doesn't
> break arch/subarch specific patches (can be automated to a degree),
> and fix those.
>
The way that arch/subarch specific patches are handled needs to be thought
out. There are architectures that are close to linus kernels, and there
are those that aren't. The preferred way to do things is to have
something similar to what k-s does now; all patches (whether arch-specific
or not) are applied. Of course, when arch-specific patches end up being
megabytes in size, and conflict w/ each other, I realize that we need
another layer on top of that; patches that are only applied to k-s when
building for a certain arch. This does add complexity, though. I'd like
to avoid that, if possible. If that means working really hard to get
upstream to sync up w/ arch-specific stuff, so be it (really, that seems
like a better long term solution then to add infrastructure to allow more
and more source drift away from linus' kernels for each arch).
> B) the security team launches the build on the security network,
> resulting in a set of security fixed .debs/.udebs.
>
> C) the security/d-i rebuilds d-i with those kernels. Should take less
> than a day, i believe, since we mostly already do daily builds of
> those.
>
> D) the iso images are autobuilt on a fast machine (i hear there is a
> new one available that does the job pretty fast), which may even if
> possible be only a partial rebuild because only a small subset of
> packages will need to be changed.
>
> Only A includes the real work, B-C can be automated, and the time delay
> on those can be quantified and get an upper bound. I believe this is a
> good solution, which i would have pushed for etch, but which i feel we
> do need for the sarge release, even if this means a little delay,
> altough this delay can be minimal indeed since the work can happen in
> parallel with the rest of the RC bug fixing, and we can easily check
> that the new kernels produce the exact same files built from the exact
> same sources/patches with the exact same configs, except for build host
> and timestamp modification they should even be md5sum equal, as was
> shown in the 2.4.27 powerpc kernel migration to a single package.
>
Again, it all depends on when sarge releases. I'm not willing to delay
sarge. It's already much too late as it is. However, if we can get all
the details of this worked out in sid, and it's solid, and sarge still
hasn't released by that point, we can probably push for it.
> Now, for this to be fully efficient, there is still a little change that
> needs done to d-i. Support for the kernel meta-packages for all arches.
>
> A common kernel-official or whatever package will be created, including
> all the kernel-latest or whatever fixes, and base-installer will
> exclusively install those packages (altough at lower priority it could
> propose to bypass them or something), since this is needed to make
> abi-breaking arches kernel security uploads transparent to the user
> doing an apt-get upgrade.
>
> Ok, this is my proposal, i am waiting for feedback, and i hope those
> that put me in your blacklist would reconsider and still follow up on
> this proposal.
>
One of the things not mentioned was ABI stuff. I implemented an
ABI-check-during-build for ubuntu, but I don't feel that's a long term
solution; really, I don't care for our current ABI handling at all. I
don't want to deal w/ package renames, nor do I want to deal w/ toolchain
breakage fucking our ABI, and other misc things that might happen. I
had intended to brainstorm w/ fabbione and other people at the next
ubuntu conference regarding this, but I'll mention my thoughts now, as
well.
We can assume, if the user is keeping up on kernel upgrades, that they
either have a kernel build environment installed, or have a central
machine that does builds for them. If they're not keeping up on
kernel upgrades.. Well, they should be, unless they're completely
disconnected from the internet or something. There is always some manual
work involved during an ABI-changing upgrade; every upgrade means a
rebuild of third party modules on some machine.
My idea is to do away w/ ABI considerations, and instead compile modules
in the kernel's postinst. This would happen for every kernel upgrade, iff
there are third party modules registered w/ the system. The way this
might look is:
- hostap-source installs /usr/src/modules/hostap.tar.bz2, and depends upon
gcc, make, bzip2, and module-assistant.
- kernel-image-2.6.10-686 (pre-?)depends upon kernel-headers-2.6.10-686.
- During k-i-2.6.10-686's preinst, for each module tarball in
/usr/src/modules, untar and build using module-assistant. If any build
fails, abort the upgrade/install. If all builds succeed, proceed with the
upgrade/install
- During k-i-2.6.10-686's postinst, for each module tarball in
/usr/src/modules, install the appropriate module package (built in
preinst).
Cons:
- kernel-image* will depend upon kernel-headers, so that's extra space
being used.
- module packages will depend upon a build environment; this wasn't
previously the case. People running a server, where they are grabbing
pre-built module packages from a central server might not like this.
- third party modules which aren't packaged will break during upgrades.
This is a problem when a package expects things to be done The Debian Way,
and things aren't. We can mitigate this risk by making it easy to convert
a third party module into something built as a package; specifically, I'm
thinking of a tool that, when run in a source directory, adds
necessary debian/* stuff, tars it up, copies it to /usr/src/modules, and
assumes the module builds correctly against our kernel headers (otherwise,
how did the user plan to compile the module anyways?). So, even though
this tarball doesn't have a foo-source package installed, during a kernel
upgrade, it attempts to build it w/ module-assistant. The debian/* stuff
would probably be the most complex part of this; it would have to figure
out the name, and what arguments are needed to make.
- Slower kernel upgrade/installs, if using third party modules. I don't
think people generally have too many third party modules; however, with
splitting out kernel-source-nonfree as a modules package (which would be
further split up into per-module packages, if it gets too large), we could
see the number of third-party modules balloon.
Pros:
- gcc and friends will only need to be installed if there are actually
third party modules installed; otherwise, if someone's using a stock
debian kernel w/ no additional modules, kernel-headers* is the only
additional package installed.
- no more ABI. Everytime a new kernel's installed, all modules are
updated. If modules can't be updated, it's up to the admin to either
remove the module, fix it, or keep running an older kernel. This also
lets the admin know right away that the thing won't build. I've heard
cases where a user installed a new kernel (say, 2.6.10), removed the old
kernel (2.6.9), rebooted, and then realized ndiswrapper-source wouldn't
build against the new kernel. At that point, they were without
networking, though (heh).
- kernel transitions are simplified. No more need for binary module
packages in the archive (a la hostap-modules-i386, alsa modules, etc).
Each time we bumped the ABI, we had to rebuild this stuff; not anymore.
The pros outweigh the cons, IMO. I'm open to any suggestions, alternate
ideas, improvements, etc. Please don't take this as anything other than
an idea which hasn't been fully hashed out yet.
Reply to: