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

2010-06-28 Thread maximilian attems
On Mon, 28 Jun 2010, Ben Hutchings wrote:

 2. Packages for boot loaders that need to be updated whenever the files
 they load are modified must also install hook scripts in
 /etc/mkinitramfs/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.

Please rename to more generic /etc/initramfs path.
mkinitramfs is initramfs-tools specific.
otherwise ack.
 
 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.]

not twice but multiple times, if you upgrade together for example
udev, lvm2, cryptsetup, mdadm and linux-2.6.
 
 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/mkinitramfs/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.  [Is this sensible or is it too 'clever'?]

what is the intent of that point?
sorry you lost me here.
 
 5. Kernel and initramfs builder packages must not invoke boot loaders
 except via hooks.  If /etc/kernel-img.conf contains an explicit
 'do_bootloader = yes', kernel package maintainer scripts should warn
 that this is now ignored.

for backward compat and upgrade purpose from lenny,
I think the must is wrong.
 
 6. The installer must not define do_bootloader, postinst_hook or
 postrm_hook in /etc/kernel-img.conf.
 ---

thanks

-- 
maks


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20100628084532.ga23...@stro.at



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

2010-06-28 Thread Stephen Powell
I took the liberty of adding debian-boot and debian-s390 to the CC
list on this e-mail, since it affects the Debian installer and
the s390-tools package, which contains the zipl boot loader, which
has a design very similar to that of lilo.  If this results in some people
getting more than one copy of this e-mail, please accept my apologies; but
I figured it was better to err on the side of caution in this case.
I also added Joachim Wiedorn, the new lilo upstream maintainer (who
also happens to be the Debian package maintainer for backup2l).

On Sun, 27 Jun 2010 22:02:35 -0400 (EDT), Ben Hutchings wrote:
 
 I propose the following policy for squeeze and later releases.  This
 affects all Linux kernel, initramfs builder and boot loader packages,
 and the installer.
 
 I regret that this is happening so late in the release cycle, but
 currently a kernel update can easily leave the system unbootable and
 this does need to be addressed before release and I want to do so in a
 way that is reasonably clean and maintainable.
 
 ---
 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.
 
 The arguments given to all kernel hook scripts are the kernel ABI
 version (the string that uname -r reports) and the absolute path to the
 kernel image.

Currently, hook scripts invoked by a stock kernel maintainer script
or a maintainer script from a kernel image package created by make-kpkg
pass these exact same arguments.  But a maintainer script for a kernel
image package created by make deb-pkg passes only the first argument.
Existing hook scripts rely on that difference to determine whether or
not to take action.  For example, the initramfs hook script provided by
the initramfs-tools package tests the number of arguments and exits
without doing anything if more than one argument is supplied.  In other
words, this hook script is designed to create the initial RAM file system
for a kernel image created by make deb-pkg, and only for a kernel
image created by make deb-pkg.  It does nothing otherwise.  Are you
proposing to change this behavior?

 The environment variable DEB_MAINT_PARAMS will contain
 the arguments given to the kernel maintainer script, single-quoted.

Is this environment variable provided by the maintainer scripts
that come with kernel image packages created by make deb-pkg?
(I honestly don't know.  I've never used make deb-pkg.)

 
 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.
 
 2. Packages for boot loaders that need to be updated whenever the files
 they load are modified must also install hook scripts in
 /etc/mkinitramfs/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.]
 
 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/mkinitramfs/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.  [Is this sensible or is it too 'clever'?]
 
 5. Kernel and initramfs builder packages must not invoke boot loaders
 except via hooks.  If /etc/kernel-img.conf contains an explicit
 'do_bootloader = yes', kernel package maintainer scripts should warn
 that this is now ignored.

At the risk of flogging a dead horse, I would prefer to see
do_bootloader = yes supported until Squeeze+1, both by the
kernel maintainer scripts and by update-initramfs -u, particularly
since we are so close to a freeze.  But if
you're going to drop support for it in Squeeze, then yes,
a warning message is necessary.  Both the kernel maintainer scripts
*and* update-initramfs -u *must* issue a warning message if they
find do_bootloader = yes specified in /etc/kernel-img.conf.
In fact, since 

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

2010-06-28 Thread Joachim Wiedorn
Hello William,

perhaps you have read the recent email from Ben (see below). It would be
important to update the lilo package to support these recent requirements
to prepare LILO for Squeeze before it will get stable.

Do you have the intention to update the lilo package to integrate some
scripts for these recent requirements?

Have a nice day,

Joachim (Germany)

---

Ben Hutchings b...@decadent.org.uk wrote on 2010-06-28 03:02:

 I propose the following policy for squeeze and later releases.  This
 affects all Linux kernel, initramfs builder and boot loader packages,
 and the installer.
 
 I regret that this is happening so late in the release cycle, but
 currently a kernel update can easily leave the system unbootable and
 this does need to be addressed before release and I want to do so in a
 way that is reasonably clean and maintainable.
 
 ---
 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.
 
 The arguments given to all kernel hook scripts are the kernel ABI
 version (the string that uname -r reports) and the absolute path to the
 kernel image.  The environment variable DEB_MAINT_PARAMS will contain
 the arguments given to the kernel maintainer script, single-quoted.
 
 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.
 
 2. Packages for boot loaders that need to be updated whenever the files
 they load are modified must also install hook scripts in
 /etc/mkinitramfs/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.]
 
 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/mkinitramfs/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.  [Is this sensible or is it too 'clever'?]
 
 5. Kernel and initramfs builder packages must not invoke boot loaders
 except via hooks.  If /etc/kernel-img.conf contains an explicit
 'do_bootloader = yes', kernel package maintainer scripts should warn
 that this is now ignored.
 
 6. The installer must not define do_bootloader, postinst_hook or
 postrm_hook in /etc/kernel-img.conf.
 ---
 
 I'm particularly interested to hear whether there are any upgrade issues
 I have not addressed.
 
 Ben.
 


signature.asc
Description: PGP signature


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

2010-06-28 Thread maximilian attems
On Mon, Jun 28, 2010 at 11:16:58AM -0400, Stephen Powell wrote:
  ---
  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.
  
  The arguments given to all kernel hook scripts are the kernel ABI
  version (the string that uname -r reports) and the absolute path to the
  kernel image.
 
 Currently, hook scripts invoked by a stock kernel maintainer script
 or a maintainer script from a kernel image package created by make-kpkg
 pass these exact same arguments.

no.

 But a maintainer script for a kernel
 image package created by make deb-pkg passes only the first argument.

no.

 Existing hook scripts rely on that difference to determine whether or
 not to take action.  For example, the initramfs hook script provided by
 the initramfs-tools package tests the number of arguments and exits
 without doing anything if more than one argument is supplied.  In other
 words, this hook script is designed to create the initial RAM file system
 for a kernel image created by make deb-pkg, and only for a kernel
 image created by make deb-pkg.  It does nothing otherwise.  Are you
 proposing to change this behavior?

please get your facts right before spamming the world.

kthxbye.


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20100628164510.gb9...@baikonur.stro.at



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

2010-06-28 Thread Stephen Powell
On Mon, 28 Jun 2010 12:45:10 -0400 (EDT), maximilian attems wrote:
 On Mon, 28 Jun 2010 03:02:35 +0100 Ben Hutchings wrote:
 The arguments given to all kernel hook scripts are the kernel ABI
 version (the string that uname -r reports) and the absolute path to the
 kernel image.
 On Mon, Jun 28, 2010 at 11:16:58AM -0400, Stephen Powell wrote:
 Currently, hook scripts invoked by a stock kernel maintainer script
 or a maintainer script from a kernel image package created by make-kpkg
 pass these exact same arguments.
 
 no.

From a Squeeze system running a custom kernel created by make-kpkg:

-

debian3:~# dpkg-reconfigure linux-image-2.6.32-custom5b-s390x
Running depmod.
Examining /etc/kernel/postinst.d.
run-parts: executing /etc/kernel/postinst.d/S30initramfs 2.6.32-custom5b-s390x 
/boot/vmlinuz-2.6.32-custom5b-s390x
 ^ ^
 +-- 1st argument  
+-- 2nd argument
  
-

From a Squeeze system running a stock kernel image:

-

r...@testdebian:~# dpkg-reconfigure linux-image-2.6.32-3-686
Running depmod.
Running update-initramfs: Generating /boot/initrd.img-2.6.32-3-686
Examining /etc/kernel/postinst.d.
run-parts: executing /etc/kernel/postinst.d/S30initramfs 2.6.32-3-686 
/boot/vmlinuz-2.6.32-3-686
 ^^
 |+-- 2nd 
argument
 +-- 1st argument

-

Q.E.D.

 On Mon, Jun 28, 2010 at 11:16:58AM -0400, Stephen Powell wrote:
 But a maintainer script for a kernel
 image package created by make deb-pkg passes only the first argument.
 
 no.

The actual text of /etc/kernel/postinst.d/initramfs-tools:

-

#!/bin/sh

version=$1
bootopt=

# passing the kernel version is required
[ -z ${version} ]  exit 0

# kernel-package passes an extra arg
if [ -n $2 ]; then
if [ -n ${KERNEL_PACKAGE_VERSION} ]; then
bootdir=$(dirname $2)
bootopt=-b ${bootdir}
else
# official Debian linux-images take care themself
exit 0
fi
fi

# avoid running multiple times
if [ -n $DEB_MAINT_PARAMS ]; then
eval set -- $DEB_MAINT_PARAMS
if [ -z $1 ] || [ $1 != configure ]; then
exit 0
fi
fi

# we're good - create initramfs.  update runs do_bootloader
update-initramfs -c -t -k ${version} ${bootopt}

-

I admit that I have never personally used make deb-pkg, but
clearly the source code speaks for itself.  This hook script is
expecting only one argument when invoked by make deb-pkg.

Q.E.D.

 On Mon, Jun 28, 2010 at 11:16:58AM -0400, Stephen Powell wrote: 
 Existing hook scripts rely on that difference to determine whether or
 not to take action.  For example, the initramfs hook script provided by
 the initramfs-tools package tests the number of arguments and exits
 without doing anything if more than one argument is supplied.  In other
 words, this hook script is designed to create the initial RAM file system
 for a kernel image created by make deb-pkg, and only for a kernel
 image created by make deb-pkg.  It does nothing otherwise.  Are you
 proposing to change this behavior?
 
 please get your facts right before spamming the world.

OK, you're partly right on this one.  Execution tracing shows that it
does nothing when invoked by a stock kernel maintainer script but
does create an initial RAM file system when invoked by a maintainer
script from a kernel image package created by make-kpkg.  (By the way,
since this script is running under debconf, output from update-initramfs
should be redirected to standard error via 2.)  I don't remember the
kernel-package logic being present in this script the last time I looked
at it.

(1) As far as I am able to determine, my original statements are correct,
with the exception of the correction made in the above paragraph.
If you can prove me wrong, please do so.
(2) This was not spam.  Spam is unsolicited advertising.
This was a response to an RFC, to which I was explicitly
included as an adressee.
(3) All the addressees of my e-mail were legitimate stake-holders
in this process.  This is not the world.

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


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



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

2010-06-28 Thread Colin Watson
On Mon, Jun 28, 2010 at 03:02:35AM +0100, Ben Hutchings wrote:
 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.

It seems to me (particularly from the fact that you upgraded a grub2 bug
report about this to important - GRUB 2 does not store block lists for
kernels) that this is not limited to boot loaders that store block lists
for the files they load: it also affects boot loaders that need to be
updated whenever the *list* of files they load is modified.  Can you
confirm that my understanding is correct?

 2. Packages for boot loaders that need to be updated whenever the files
 they load are modified must also install hook scripts in
 /etc/mkinitramfs/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.

Does the same apply here, or not?  This is going to be quite a lot of
calls to update-grub if so, although at least it's quite a bit faster
now than it used to be ...

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

Is an initramfs guaranteed to be built before any of the boot loader
hooks are executed?  It seems like a waste of time calling boot loader
hooks otherwise.  (This may be implied by your design, but it was a
little bit implicit if so.)

 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/mkinitramfs/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.  [Is this sensible or is it too 'clever'?]

Sensible, I think.  There's no point running update-grub three times.

-- 
Colin Watson   [cjwat...@debian.org]


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20100628221906.ga28...@master.debian.org



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

2010-06-28 Thread Ben Hutchings
On Mon, 2010-06-28 at 22:19 +, Colin Watson wrote:
 On Mon, Jun 28, 2010 at 03:02:35AM +0100, Ben Hutchings wrote:
  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.
 
 It seems to me (particularly from the fact that you upgraded a grub2 bug
 report about this to important - GRUB 2 does not store block lists for
 kernels) that this is not limited to boot loaders that store block lists
 for the files they load: it also affects boot loaders that need to be
 updated whenever the *list* of files they load is modified.  Can you
 confirm that my understanding is correct?

Sorry, I managed to lose this sentence during editing:

'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/mkinitramfs/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.
 
 Does the same apply here, or not?  This is going to be quite a lot of
 calls to update-grub if so, although at least it's quite a bit faster
 now than it used to be ...

No.

  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.]
 
 Is an initramfs guaranteed to be built before any of the boot loader
 hooks are executed?  It seems like a waste of time calling boot loader
 hooks otherwise.  (This may be implied by your design, but it was a
 little bit implicit if so.)
[...]

This requirement and the naming requirements on hook scripts are
intended to guarantee that.

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] Policy for Linux kernel, initramfs, boot loader update process

2010-06-28 Thread Ben Hutchings
Please reply to debian-kernel only.

On Mon, 2010-06-28 at 11:16 -0400, Stephen Powell wrote:
 On Sun, 27 Jun 2010 22:02:35 -0400 (EDT), Ben Hutchings wrote:
[...]
  The environment variable DEB_MAINT_PARAMS will contain
  the arguments given to the kernel maintainer script, single-quoted.
 
 Is this environment variable provided by the maintainer scripts
 that come with kernel image packages created by make deb-pkg?
 (I honestly don't know.  I've never used make deb-pkg.)

It has done since 2.6.31, though without single-quotes.  I'll note that
they may or may not be quoted, and recommend how to use this variable.

[...]
  5. Kernel and initramfs builder packages must not invoke boot loaders
  except via hooks.  If /etc/kernel-img.conf contains an explicit
  'do_bootloader = yes', kernel package maintainer scripts should warn
  that this is now ignored.
 
 At the risk of flogging a dead horse, I would prefer to see
 do_bootloader = yes supported until Squeeze+1, both by the
 kernel maintainer scripts and by update-initramfs -u, particularly
 since we are so close to a freeze.

The release team has stated we are not close to a freeze.  So we have a
little time to sort this out.

 But if
 you're going to drop support for it in Squeeze, then yes,
 a warning message is necessary.  Both the kernel maintainer scripts
 *and* update-initramfs -u *must* issue a warning message if they
 find do_bootloader = yes specified in /etc/kernel-img.conf.
 In fact, since the default value is yes, they should issue
 the warning message unless do_bootloader is *explicitly* set
 to no.

I can put a one-time warning into linux-base.  But the default for
squeeze must be 'no'.  It should not be necessary to create
/etc/kernel-img.conf at all in squeeze.

  6. The installer must not define do_bootloader, postinst_hook or
  postrm_hook in /etc/kernel-img.conf.
 
 Doesn't this conflict with point 4 (a)?

Not at all.  This means postinst_hook and postrm_hook are now strictly
for use by the user.

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] Policy for Linux kernel, initramfs, boot loader update process

2010-06-28 Thread Ben Hutchings
On Mon, 2010-06-28 at 18:45 +0200, maximilian attems wrote:
[...]
 please get your facts right before spamming the world.

Max, this is rude and unjustified.

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


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

2010-06-27 Thread Ben Hutchings
I propose the following policy for squeeze and later releases.  This
affects all Linux kernel, initramfs builder and boot loader packages,
and the installer.

I regret that this is happening so late in the release cycle, but
currently a kernel update can easily leave the system unbootable and
this does need to be addressed before release and I want to do so in a
way that is reasonably clean and maintainable.

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

The arguments given to all kernel hook scripts are the kernel ABI
version (the string that uname -r reports) and the absolute path to the
kernel image.  The environment variable DEB_MAINT_PARAMS will contain
the arguments given to the kernel maintainer script, single-quoted.

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.

2. Packages for boot loaders that need to be updated whenever the files
they load are modified must also install hook scripts in
/etc/mkinitramfs/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.]

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/mkinitramfs/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.  [Is this sensible or is it too 'clever'?]

5. Kernel and initramfs builder packages must not invoke boot loaders
except via hooks.  If /etc/kernel-img.conf contains an explicit
'do_bootloader = yes', kernel package maintainer scripts should warn
that this is now ignored.

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

I'm particularly interested to hear whether there are any upgrade issues
I have not addressed.

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