On Sun, 04 Jul 2010 13:48:20 -0400 (EDT), Ben Hutchings wrote: > > 0. The arguments given to all kernel hook scripts are the kernel ABI > version (the string that uname -r reports) and, optionally, the absolute > path to the kernel image. If the second argument is missing then the > path is either /boot/vmlinuz-$version or /boot/vmlinux-$version, > according to architecture convention.
Pardon my ignorance, but what architectures use the vmlinux convention rather than the vmlinuz convention? I've only worked with the i386 and s390 architectures, and they both use the vmlinuz convention. Perhaps more importantly, why do these architectures use the vmlinux naming convention and why is it important to maintain a separate naming convention? Wouldn't it be simpler to use the same naming convention on all architectures? No doubt this has been discussed before, but I'm new at this. Feel free to refer me to a previous discussion thread if appropriate. > > ... > Kernel hook scripts may be run under debconf. In this case they must > not use stdin and stdout, and should send all output to stderr (fd 2). > [Alternately we should change linux-2.6 and kernel-package to do the > necessary redirection. Is there any legitimate reason for a hook script > to interact with debconf?] So far, I have had no requirement to interact directly with debconf in a hook script, but why close out our options? If you redirect standard output to standard error at, say, the invocation of the run-parts command, then the hook script *cannot* interact with debconf, even if it wants to or needs to. If you leave things as they are now, the hook script will normally redirect standard output to standard error, but if for some unforeseen reason it later needs or wants to interact with debconf, it can. Therefore, I would prefer to leave things as in the first quoted sentence above. That's my two cents worth. > 2. Packages for boot loaders that need to be updated whenever the files > they load are modified must also install hook scripts in > /etc/initramfs/post-update.d. Initramfs builders must call these > scripts using run-parts after they create, update or delete an > initramfs. The arguments given to these hook scripts are the kernel ABI > version and the absolute path to the initramfs image. My template hook script for this directory currently tests whether a maintainer script beginning with "linux-image-" is being processed, and, if so, exits without doing anything. Presumably, only such a maintainer script will create or delete an initramfs. At least that is my assumption. Upon further reflection, however, maybe I should expand this test to look for Hurd kernels and FreeBSD kernels? I don't know how to test for those. Alternately, the hook script needs some way of determining whether it is being called for a create, delete, or update. In my case anyway, the hook script is only interested in an update (to match the current behavior of update-initramfs). -- .''`. Stephen Powell : :' : `. `'` `- -- To UNSUBSCRIBE, email to [email protected] with a subject of "unsubscribe". Trouble? Contact [email protected] Archive: http://lists.debian.org/609145822.187199.1278422298504.javamail.r...@md01.wow.synacor.com
