Continuing to use old kernels for installation after point releases
I have a setup at work which, amongst other things, regularly
autoinstalls Debian. Because I don't want it to break unexpectedly, I
prefer to keep using old installation kernels - for example, new
kernels may have different requirements for non-free firmware etc., so
I think it's not trivial to just use whatever kernel is in the most
recent Debian point release.
There are other reasons why someone might prefer to keep using an
existing installer kernel even after a Debian point release: for
example, doing otherwise would mean that the autoinstaller would have
to check the Debian archive and perhaps suck down a new
kernel/initramfs automatically and drop them into the pxe directory -
and it seems to me that even such an arrangement would be subject to a
race, where it would start to install with one set of images but by
the time it comes along to get the other components they would be
gone.
At the moment keeping the same images is awkward, because (AFAICT) at
a Debian point release the kernel modules required by the old kernel
are removed from the archive. This makes the old netboot installer
images break.
This was extensively discussed in this thread:
http://lists.debian.org/debian-devel/2011/11/msg00481.html
I've just reread the thread. Some of it seemed rather bad-tempered
and I'd like to distance myself from the criticism of the kernel
team. I quite understand why it's considered a good idea to update
the installation kernel. For most people that's the right thing to
do.
However, I'd still like to try to understand whether it is possible to
make this work better for those of us who have setups where we launch
the installer via pxe and we only want to take new kernel/initramfs
versions when we explicitly choose to do so.
If it's a question of needing someone to do some work, I have effort
available for this. After all it'll stop my infrastructure at work
breaking every time there's a Debian point release.
Alternatively, perhaps I and others (since it's not just me that has
this problem) are just going about things entirely the wrong way. In
which case I'd be happy to help update documentation or whatever but
at the moment I'm afraid I don't know what the better way would be.
The simplest solution, suggested by several people in the thread,
would be not to remove the old udebs from the archive. I don't know
whether that's possible, but no-one seemed to give an authoritative
answer to that suggestion previously.
Thanks,
Ian.
Reply to: