Debian kernel packaging: changes forthcoming in kernel-package 11.x
Hi,
[Please follow up on debian-kernel@lists.debian.org]
The postinst script of the kernel image packages is huge -- but
then, it comes from a tradition of a postinst that would ask you if you
wanted to put the new kernel on a boot floppy, format and initialize a
new floppy, and create a bootable floppy from the newly installed
image. Thankfully, the format-and-create-boot-floppy functionality was
removed from the postinst, but still a number of things remain hard-coded
into the postinst.
Apart from the fact that this functionality has been the cause
of much teeth gnashing and many bug reports, since the complexity of
the logic is one of the most bug-prone bits of the image postinst, it
also makes it harder to come up with alternatives to the algorithms or
to tweak the behavior -- since one needs to tweak kernel-package,
re-compile the kernel, and install it, to see new behavior. For
example, what if I want to create symlinks for the three most recent
2.4, 2.6, and Xen images? It should be a simple task, but currently it
is not.
With /etc/kernel/*.d directories, we have a means of having the
sysadmin installing arbitrary bits of code in these directories, to
do whatever they wish to post process the image so installed.
So I plan on moving the symlink handling out of the postinst.
Instead of the postinst creating the symlinks, people can drop in a
script that does symlink handling for them. This should not be a big
deal for most people now, since update-grub does not really need the
symlinks anyway.
Secondly, the postinst will no longer run the boot-loader (it
does not do so for grub right now). Again, a simple run_loader script
can be put in place in the /etc/kernel/ directories, for people who
need them.
I think the packages affected might be lilo, quik, palo,
vmelilo, zipl, and elilo. These packages might want to drop in a
script that runs on install/remove into /etc/kernel; examples should be
easy to provide.
Third, I want to do away with the postinst deciding which initrd
generator to run. The current initramfs packages already have commands
to create the initrd; and these packages can again dump in scripts to
run the initrd generator in /etc/kernel/*.d. This is the chance that
initrd generator people have to fix the interface that they have been
complaining about.
Finally, I want to have kernel-package come closer to the
version numbering scheme that the official kernel images have been
using, complete with native flavour support, but this can be dealt with
in a separate thread.
The critical issues are:
a) How to configure which one of competing boot-loader scripts get run,
if more than one boot loaders are installed
b) Which initramfs generator gets run, if we have more than one
installed.
c) What information would the scripts need, apart from kernel version,
and the location of the image?
d) How do we transition the changes -- wait for all involved packages
to create a changed version, and upload all packages at once in a
staged fashion, or just stagger it into Sid?
The first two issues are specific instances of the general
problem of how to configure any set of cooperating scripts; and a
solution similar to those used for init scripts can be adopted
(/etc/default/script-or-package-name)
So, the next step should be to create example symlink,
boot-loader invocation, and initrd invocation scripts for people to dump
into /etc/kernel. I was thinking of also including these examples into
the kernel image packages, even if there is some duplication on disk
of these small examples, at least while the transition is still going
on.
manoj
--
The PINK SOCKS were ORIGINALLY from 1952!! But they went to MARS around
1953!!
Manoj Srivastava <srivasta@debian.org> <http://www.debian.org/~srivasta/>
1024D/BF24424C print 4966 F272 D093 B493 410B 924B 21BA DABB BF24 424C
Reply to: