FAQ Search Today's Posts Mark Forums Read
» Video Reviews

» Linux Archive

Linux-archive is a website aiming to archive linux email lists and to make them easily accessible for linux users/developers.

» Sponsor

» Partners

» Sponsor

Go Back   Linux Archive > Debian > Debian Kernel

LinkBack Thread Tools
Old 03-24-2009, 10:11 PM
Frans Pop
Default Standardizing use of kernel hook scripts

Hi all,

I'm not sure whether this discussion should happen here (d-kernel +
selected interested parties) or would be better held on d-devel.
If ppl think it would be better on d-devel, then please let me know and
I'll restart it there.

Sorry if any of this has already been discussed or documented. I must
admit I've not looked very hard.


(I've subscribed to d-kernel for this discussion but don't mind CCs in
this case.)

For the past year and more I've been building upstream kernels without
using any Debian tools, by just calling the kernel's own 'make deb-pkg'

The maintainer scripts for the thus generated kernel image package don't
do anything but call hook scripts in /etc/kernel/{pre,post}{inst,rm}.d/.

Current official Debian kernels (at least up to 2.6.26) also call any
scripts there and so do kernel packages built using make-kpkg.

I've seen that the new squeeze version of initramfs-tools now installs
hook scripts in those dirs [1]. I think the kernel team is planning to
switch to a general use of the hook scripts for squeeze.

A grep through the lintian lab showed ltsp-client as the only other
package that installs hook scripts there.

For my kernel testing I've been using some patches for the deb-pkg target
which I'd now like to push upstream. While I was finalizing them, I ran
into some issues I'd like to discuss with you.

In general the kernel team should be aware that there _are_ other current
users of /etc/kernel/ hook scripts.

[1] Although I did not see it mentioned in the changelog.

My patch series for the upstream kernel contains roughly the following
- some minor cleanup
- a fix so that the arm kernel image gets found (use of KBUILD_IMAGE is
not completely standard across arches)
- a way to pass maintainer script parameters to hook scripts (see below)
- an option to specify a custom package version/revision
- an option to use a different hook scripts directory from /etc/kernel
(I currently use /etc/kernel.custom to avoid my hook scripts to be
run when I install an official Debian kernel package)

The last patch provides a general escape, but it would be nice if all
Debian kernel packages could use the same hook scripts. (/me dreams)

Note that none of my patches affect Debian kernel builds as they don't use
the deb-pkg target.

Parameters passed to hook scripts
Official Debian kernels (at least up to 2.6.26) and make-kpkg based
packages pass two parameters:
- kernel version
- $realimageloc$kimage-$version (/boot/vmlinuz-<kvers>)

deb-pkg based packages only pass the kernel-version.

AFAICT ltsp-client hook scripts use neither of these parameters.

New initramfs-tools hook scripts uses the kernel version and includes a
hack that tests if $2 is defined to avoid running with pre-squeeze
kernels and make-kpkg kernels. Not ideal...

There is legacy here which makes any transition hard. But given the
limited existing users of hook scripts I think we can essentially ignore,
but it would be good to agree on a standard for the future!

Is anything other than the kernel version really needed?

Maintainer script parameters
Currently maintainer script parameters are not passed on to the hook
scripts, but IMO they could be very useful, for example: a bootloader
update only needs to be run on package removal, but not on purge.

Given the previous point I think adding them to the parameters passed to
the hook scripts is not a good option. I therefore propose to instead
export them in a standard environment parameter. Proposal:
export DEB_MAINT_PARAMS="$@"

Execution order of hook scripts
Both initramfs-tools and ltsp-client currently just dump a script in the
hook dirs without any naming convention. If many packages were to do
that, chaos would be a guaranteed result.

IMO scripts should have standardized names starting with numbers to
regulate execution order. Ranges should be reserved, for example:
- early scripts 00-19
- initrd generation 30-49
- bootloader update 50-69
- late scripts 80-99

Use of new numbers by packages should probably be coordinated by the
kernel team.

To conffile or not to conffile
If I'm correct neither initramfs-tools nor ltsp-client currently defines
the hook scripts as conffiles. This is both good and bad.

- good: the hook script are removed when the package is removed which
avoids the problem that it could get run after removal, but before purge
- bad: user changes in the scripts get lost on package upgrades

IMO all hook scripts should be conffiles so user changes get preserved.
But that means that they need to include a check (existence of main
package binary for example) and exit 0 if the package was removed but not

Allow user to control execution of hook scripts?
There can be various cases where this could be useful. Example would be
that it's pretty bad if you have two bootloaders installed (grub and
lilo) and both have hook scripts that get run. Some standard mechanism to
disable a particular hook script could be useful.

More advanced would be to allow to run hook scripts based on type of build
system used: official Debian kernel, make-kpkg, deb-pkg, ...
This could be done by exporting some envvar that indicates the "source",
which would also remove the need for the abovementioned hack i-t uses now
(absence of the envvar would mean "legacy").

Some standard for progress output/verbosity?
It could be useful to provide some guidelines about when and how to
display progress info. As could a general "verbose" option for debugging.

Basic infrastructure
I think some package will need to provide some basic infrastructure:
- general config options for all kernel hook scripts (see previous point)
- install a README explaining the use of kernel hook scripts
- provide a very early postinst hook that runs 'depmod -a <kvers>'; I'm
not sure how else that could be provided
- possibly be responsible for creating/updating symlinks, although that's
always a tough one as you might want symlinks updated for official
kernels but not for custom built ones (or use different symlinks for
custom kernels); the suggested "source" envvar could help there
- provide a shell library file with functions to implement some of the
ideas mentioned above

Thread Tools

All times are GMT. The time now is 01:11 AM.

VBulletin, Copyright ©2000 - 2014, Jelsoft Enterprises Ltd.
Content Relevant URLs by vBSEO ©2007, Crawlability, Inc.
Copyright 2007 - 2008, www.linux-archive.org