[DRAFT v2] Policy for Linux kernel, initramfs, boot loader update process

[Ben Hutchings]

I think this incorporates all the comments and corrections for the
previous version.  Please send follow-ups to debian-kernel, and
subscribe to it if you haven't already done so.

Ben.

---
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.  The environment variable
DEB_MAINT_PARAMS will contain the arguments given to the kernel
maintainer script, possibly single-quoted.  In a shell script, this
variable can be parsed using 'set -- $DEB_MAINT_PARAMS'.

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?]

1. Packages for boot loaders that need to be updated whenever the files
they load are modified (i.e. those that store a block list) must install
hook scripts in /etc/kernel/postinst.d and /etc/kernel/postrm.d, which
will be called on installation/upgrade and removal of kernel packages,
respectively.

Since these boot loaders should be updated as the last step during
installation/upgrade and removal, hook scripts for boot loaders must be
named using the prefix 'zz-' and no other packages may use this prefix
or one that sorts later by the rules used by run-parts.  A postrm hook
script should warn but exit with code 0 if the boot loader configuration
file still refers to the kernel image that has been removed.

Packages for boot loaders that can provide a menu of kernel versions
should install kernel hook scripts in order to update that menu.

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.

3. Initramfs builders must complete their work before returning from the
kernel postinst hook script.  [initramfs-tools currently uses a trigger
to defer this because it can also be invoked twice, but this means it
also has to know how to update specific boot loaders.  This new
requirement will allow boot loader packages to avoid unnecessary
updates, as described in the following section.]

4. During a kernel package installation, upgrade or removal, various
boot loader hooks may be invoked (in this order):

a. A postinst_hook or postrm_hook command set by the user or the
   installer in /etc/kernel-img.conf
b. A hook script in /etc/initramfs/post-update.d
c. A hook script in /etc/kernel/postinst.d or .../postrm.d

To avoid unnecessary updates, the hooks invoked at step a and b may
check whether $DPKG_MAINTSCRIPT_PACKAGE begins with 'linux-image-' and
do nothing in this case.

5. Kernel packages must not invoke boot loaders except via hooks.
If /etc/kernel-img.conf contains 'do_bootloader = yes' or equivalent,
maintainer scripts that previously acted on this must warn that they are
ignoring it.  linux-base must also warn on upgrade that the default has
changed.  In squeeze+1, this prohibition extends to initramfs builder
packages.

6. The installer must not define do_bootloader, postinst_hook or
postrm_hook in /etc/kernel-img.conf.

-- 
Ben Hutchings
Once a job is fouled up, anything done to improve it makes it worse.


signature.asc
Description: This is a digitally signed message part

Re: [DRAFT v2] Policy for Linux kernel, initramfs, boot loader update process

[Stephen Powell]

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 debian-kernel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: 
http://lists.debian.org/609145822.187199.1278422298504.javamail.r...@md01.wow.synacor.com

Re: [DRAFT v2] Policy for Linux kernel, initramfs, boot loader update process

[Ben Hutchings]

On Tue, 2010-07-06 at 09:18 -0400, Stephen Powell wrote:
> 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

Hysterical raisins.

> 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.

That would require an upstream change.

> > ...
> > 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?

So that hook script authors can't make the mistake of failing to
redirect.

[...]
> > 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?
[...]

It's possible that this policy can be extended to cover them, but I just
don't know anything about their boot process.

Ben.

-- 
Ben Hutchings
Once a job is fouled up, anything done to improve it makes it worse.


signature.asc
Description: This is a digitally signed message part

Re: [DRAFT v2] Policy for Linux kernel, initramfs, boot loader update process

[Stephen Powell]

On Tue, 06 Jul 2010 09:38:53 -0400 (EDT), Ben Hutchings wrote:
> On Tue, 2010-07-06 at 09:18 -0400, Stephen Powell wrote:
>> ...
>> Perhaps more importantly, why do these architectures use the vmlinux
>> naming convention
> 
> Hysterical raisins.

I take that to mean "historical reasons".  OK.
>>
>> 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?
>> ...
> 
> That would require an upstream change.

Oh.
>> ...
>> So far, I have had no requirement to interact directly with debconf
>> in a hook script, but why close out our options?
> 
> So that hook script authors can't make the mistake of failing to
> redirect.

Well, yes, it would solve that problem.  But if redirection is
listed in the policy, and they don't do it, it's their fault.
My stuff works either way, at this point.  Do what you think is best.

>> ...
>> Upon further reflection, however, maybe I should expand this test to look
>> for Hurd kernels and FreeBSD kernels?
> 
> It's possible that this policy can be extended to cover them, but I just
> don't know anything about their boot process.

Then I'll leave it as-is for now.

-- 
  .''`. Stephen Powell
 : :'  :
 `. `'`
   `-


-- 
To UNSUBSCRIBE, email to debian-kernel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: 
http://lists.debian.org/1227172348.193220.1278429963259.javamail.r...@md01.wow.synacor.com

Re: [DRAFT v2] Policy for Linux kernel, initramfs, boot loader update process

[Thorsten Glaser]

Guillem Jover dixit:

>A bit of background info. For GNU/kFreeBSD the kernel images are named
>'kfreebsd-image-*', for GNU/Hurd they are named 'gnumach'. (I should
>probably rename gnumach to match the current kernel naming convention.)

I wonder if there will ever be packages like kmidnightbsd-image-* for
Debian GNU/kFreeBSD (it’s a relatively close fork of it, and the few
kfreebsd specific patch lines could be applied)…

bye,
//mirabilos, who’s had beers with the MidnightBSD founder recently
-- 
I believe no one can invent an algorithm. One just happens to hit upon it
when God enlightens him. Or only God invents algorithms, we merely copy them.
If you don't believe in God, just consider God as Nature if you won't deny
existence.  -- Coywolf Qi Hunt


--
To UNSUBSCRIBE, email to debian-kernel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: 
http://lists.debian.org/pine.bsm.4.64l.1007082127010.18...@herc.mirbsd.org

Re: [DRAFT v2] Policy for Linux kernel, initramfs, boot loader update process

[Guillem Jover]

Hi!

So while this was presented as a draft for Linux kernels, it touches
interfaces shared with other kernels, so I think it would be nice to
try to get it to be kernel agnostic, CCing debian-bsd@ and debian-hurd@
just for that. The complete draft can be found in debian-ker...@.

A bit of background info. For GNU/kFreeBSD the kernel images are named
'kfreebsd-image-*', for GNU/Hurd they are named 'gnumach'. (I should
probably rename gnumach to match the current kernel naming convention.)

GNU/kFreeBSD can boot using either the native FreeBSD boot loader, or
grub. GNU/Hurd can boot with any multiboot compliant boot loader.

Currently neither make use or need any initrd image to boot, due to
using boot loader loadable modules. But there's been talk about adding
initrd support to gnumach for d-i.

On Sun, 2010-07-04 at 18:48:20 +0100, Ben Hutchings wrote:
> 4. During a kernel package installation, upgrade or removal, various
> boot loader hooks may be invoked (in this order):
> 
> a. A postinst_hook or postrm_hook command set by the user or the
>installer in /etc/kernel-img.conf

kfreebsd-image-* packages honour those hooks. I'll add support for
those to gnumach.

> b. A hook script in /etc/initramfs/post-update.d

Neither kfreebsd nor gnumach honour this, not needed yet though.

> c. A hook script in /etc/kernel/postinst.d or .../postrm.d

Neither do honour these, they need support added. I can probably make
some time to do that for both.

> To avoid unnecessary updates, the hooks invoked at step a and b may
> check whether $DPKG_MAINTSCRIPT_PACKAGE begins with 'linux-image-' and
> do nothing in this case.

Take into account that DPKG_MAINTSCRIPT_PACKAGE is only set if running
under dpkg, dpkg-reconfigure (from debconf) does not set this nor other
variables yet. See #560317.

It would be nice to consider the other kernel package names. But even
nicer to just have a centralized place where all currently known package
patterns are listed or can be queried so that there's no need to update
multiple scripts on new kernel additions, or name convention changes.

> 5. Kernel packages must not invoke boot loaders except via hooks.
> If /etc/kernel-img.conf contains 'do_bootloader = yes' or equivalent,
> maintainer scripts that previously acted on this must warn that they are
> ignoring it.  linux-base must also warn on upgrade that the default has
> changed.  In squeeze+1, this prohibition extends to initramfs builder
> packages.

Neither kfreebsd-image-* nor gnumach packages have ever honoured
do_bootloader.

thanks,
guillem


-- 
To UNSUBSCRIBE, email to debian-kernel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20100708075158.gb31...@gaara.hadrons.org

Re: [DRAFT v2] Policy for Linux kernel, initramfs, boot loader update process

[Ben Hutchings]

On Thu, 2010-07-08 at 09:51 +0200, Guillem Jover wrote:
[...]
> On Sun, 2010-07-04 at 18:48:20 +0100, Ben Hutchings wrote:
> > 4. During a kernel package installation, upgrade or removal, various
> > boot loader hooks may be invoked (in this order):
> > 
> > a. A postinst_hook or postrm_hook command set by the user or the
> >installer in /etc/kernel-img.conf
> 
> kfreebsd-image-* packages honour those hooks. I'll add support for
> those to gnumach.

That is not necessary; these are already deprecated.

> > b. A hook script in /etc/initramfs/post-update.d
> 
> Neither kfreebsd nor gnumach honour this, not needed yet though.

Nor implemented at all!

> > c. A hook script in /etc/kernel/postinst.d or .../postrm.d
> 
> Neither do honour these, they need support added. I can probably make
> some time to do that for both.

Please do.

> > To avoid unnecessary updates, the hooks invoked at step a and b may
> > check whether $DPKG_MAINTSCRIPT_PACKAGE begins with 'linux-image-' and
> > do nothing in this case.
> 
> Take into account that DPKG_MAINTSCRIPT_PACKAGE is only set if running
> under dpkg, dpkg-reconfigure (from debconf) does not set this nor other
> variables yet. See #560317.

Well, this *is* an optimisation, not required for correctness.

> It would be nice to consider the other kernel package names. But even
> nicer to just have a centralized place where all currently known package
> patterns are listed or can be queried so that there's no need to update
> multiple scripts on new kernel additions, or name convention changes.

I think any package that deals with kernel images must have explicit
support for the kernel type, and it can tell the expected kernel type
based on the Debian architecture name.  So I think this abstraction is
unnecessary.

I have not added any requirements for non-Linux kernels in the policy,
but if you and the other maintainers can fully define how to extend it
to your kernels then I'm happy to include those extensions.

Ben.

-- 
Ben Hutchings
Once a job is fouled up, anything done to improve it makes it worse.


signature.asc
Description: This is a digitally signed message part

Re: [DRAFT v2] Policy for Linux kernel, initramfs, boot loader update process

[Manoj Srivastava]

On Sun, Jul 04 2010, Ben Hutchings wrote:

Sorry for the delay in replying.
> 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?]

I don't know. It depends on what the script does, I
 suppose. There is no indication what future scripts ight be used for,
 and there might be future legitimate need to interact with the user
 doing the installation. At this point, we should be "liberal in what we
 accept", I think.

manoj

-- 
The more things change, the more they'll never be the same again.
Manoj Srivastava    
4096R/C5779A1C E37E 5EC5 2A01 DA25 AD20  05B6 CF48 9438 C577 9A1C


-- 
To UNSUBSCRIBE, email to debian-kernel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/87hbjvqrgt@anzu.internal.golden-gryphon.com

Re: [DRAFT v2] Policy for Linux kernel, initramfs, boot loader update process

[Guillem Jover]

Hi!

On Sun, 2010-07-04 at 18:48:20 +0100, 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.  The environment variable
> DEB_MAINT_PARAMS will contain the arguments given to the kernel
> maintainer script, possibly single-quoted.  In a shell script, this
> variable can be parsed using 'set -- $DEB_MAINT_PARAMS'.

This should probably be 'eval set -- "$DEB_MAINT_PARAMS"' instead, or
the single quotes will not be stripped, neither any possible spaces
will be correctly preserved.

It seems from my system at least grub2 will need fixing.

regards,
guillem


-- 
To UNSUBSCRIBE, email to debian-kernel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20100806062053.ga16...@gaara.hadrons.org

Re: [DRAFT v2] Policy for Linux kernel, initramfs, boot loader update process

[Stephen Powell]

On Fri, 06 Aug 2010 02:20:53 -0400 (EDT), Guillem Jover wrote:
> 
> This should probably be 'eval set -- "$DEB_MAINT_PARAMS"' instead, or
> the single quotes will not be stripped, neither any possible spaces
> will be correctly preserved.

This is what my template scripts do.  I got that logic originally from
a template script in kernel-package

> It seems from my system at least grub2 will need fixing.

I wasn't aware that grub2 used -- or needed -- any hook scripts.
grub1, yes; but not grub2.

-- 
  .''`. Stephen Powell
 : :'  :
 `. `'`
   `-


-- 
To UNSUBSCRIBE, email to debian-kernel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: 
http://lists.debian.org/229089153.218736.1281100278973.javamail.r...@md01.wow.synacor.com

Re: [DRAFT v2] Policy for Linux kernel, initramfs, boot loader update process

[Ben Hutchings]

On Fri, 2010-08-06 at 08:20 +0200, Guillem Jover wrote:
> Hi!
> 
> On Sun, 2010-07-04 at 18:48:20 +0100, 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.  The environment variable
> > DEB_MAINT_PARAMS will contain the arguments given to the kernel
> > maintainer script, possibly single-quoted.  In a shell script, this
> > variable can be parsed using 'set -- $DEB_MAINT_PARAMS'.
> 
> This should probably be 'eval set -- "$DEB_MAINT_PARAMS"' instead, or
> the single quotes will not be stripped, neither any possible spaces
> will be correctly preserved.

You're quite right.  I've just fixed this in the Kernel Handbook.

> It seems from my system at least grub2 will need fixing.

Ben.

-- 
Ben Hutchings
Once a job is fouled up, anything done to improve it makes it worse.


signature.asc
Description: This is a digitally signed message part

Re: [DRAFT v2] Policy for Linux kernel, initramfs, boot loader update process

[Jeff Carr]

On Fri, Aug 6, 2010 at 19:54, Ben Hutchings  wrote:

>> This should probably be 'eval set -- "$DEB_MAINT_PARAMS"' instead, or
>> the single quotes will not be stripped, neither any possible spaces
>> will be correctly preserved.
>
> You're quite right.  I've just fixed this in the Kernel Handbook.

Would it be possible to add a reference to this in the linux-image
packages? dpkg -s linux-image-* doesn't have any reference to this.
Also, there is no README in this package to would point you there.

This Kernel Handbook (http://kernel-handbook.alioth.debian.org/) is
very helpful. I never knew about it until today because it wasn't
referenced anywhere in the kernel-image package (that I could find).

In other regards, thanks for maintaining this helpful information,
Jeff


--
To UNSUBSCRIBE, email to debian-kernel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: 
http://lists.debian.org/aanlkti=boe93apyrs+bjo=ho0fumlvubwggtc0kmf...@mail.gmail.com