Re: Standardizing use of kernel hook scripts
On Wed, 25 Mar 2009, Frans Pop wrote:
> 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.
think this is right place, we could/should add linux-kbuild too.
> Sorry if any of this has already been discussed or documented. I must
> admit I've not looked very hard.
no, not yet discussed.
> INTRO
> =====
> 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'
> target.
yep, nice.
> 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/.
right, we might want to fix that for depmod to have it shipped a postinst.
> 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.
i don't know if waldi's rewrite aka the dkt - debian kernel toolkit
uses the infrastructure, guess not, maybe waldi can highlight his plans?
> DEB-PKG PATCHES
> ===============
> My patch series for the upstream kernel contains roughly the following
> changes:
> - some minor cleanup
would be nice to see, can you post those linux-kbuild.
maybe as followup on mine, maybe we step on each toes with those ;)
script is not huge.
> - 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)
don't think /etc/kernel.custom is a good idea.
i'd be more happier to move that to /lib like udev that moved from
/etc/udev/rules.d/ to /lib/udev/rules.d/
> 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.
>
>
> ISSUES
> ======
> 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...
why not ideal?
have seen this same critic by k-p maintainer, but it didn't get backed up.
if you read initramfs-tools changelog you'd see that a first attempt
to have make deb-pkg support was done for lenny but failed
due to double removal of same initramfs irc.
aka #499270 version 0.92k->0.92l
> 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?
dont think so.
> 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.
nah not very useful, enforcing correct file name ending with .sh
might be more worthwhile.
> 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
> purged.
no conffile.
users shouldn't care to much about these details.
i'd prefer a /lib location and if you still see it worthwile
for powerusers the /etc conffile?!
> 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
no extra package should be needed linux-2.6 make deb-pkg should
have it's postinst fixed and should work standalone that is the
main point and greatest bonus.
have it fixed upstream for all and everyone. :)
thanks for your input and looking forward on make deb-pkg hackery.
--
maks
Reply to: