Re: [DRAFT] Policy for Linux kernel, initramfs, boot loader update process
On Wed, 30 Jun 2010 09:29:42 -0400 (EDT), Stephen Powell wrote: Since symlinks are not associated with any package in particular, and since they seem to have been designed for the convenience of historic boot loaders such as lilo and zipl, perhaps the best way to handle this is for the boot loader hook script, zz-whatever, to maintain the symlinks, if desired. As a matter of fact, I already have a hook script on hand that does this very thing, and with minor modifications will do nicely, I think. Right now, it unconditionally maintains the symlinks. To generalize it more, it could determine if symlinks already exist or not, and if so where, then maintain them where they are. If the symlinks don't exist, it won't create them. It could also be changed to determine if lilo or zipl is in use, based on the presence of the config file, and invoke the appropriate boot loader. Then, all the maintainer of the s390-tools package would have to do is to include it in the s390-tools package. And the maintainer of lilo could do the same. OK, I now have some templates to shoot at. /etc/kernel/postinst.d/zz-bootloader http://www.wowway.com/~zlinuxman/kernel/postinst.d/zz-bootloader /etc/kernel/postrm.d/zz-bootloader http://www.wowway.com/~zlinuxman/kernel/postrm.d/zz-bootloader These templates should work for both lilo and zipl, and they maintain the symbolic links, if they already exist. When doing an initial install (Debian installer), (1) the initial kernel must be installed first, then (2) the boot loader must be installed, then (3) the initial symlinks must be created (if lilo or zipl), then (4) dpkg-reconfigure or the boot loader installer (lilo or zipl) must be run. (Steps 2 and 3 could optionally be reversed or combined.) After that, the hook scripts will maintain the symbolic links as long as there is at least one installed kernel at all times. (Presumably one will never purge the running kernel!) In particular, /etc/kernel-img.conf is not examined to see if do_symlinks = yes is set. If symlinks are present, they will be maintained. If they are not, they will not be created. ... [discussion of initramfs-tools issues ] Since you're obviously very busy, I will submit a version of the initramfs-tools script which I believe will address all these issues. Then you can take pot shots at it. These are included here: /etc/kernel/postinst.d/initramfs-tools http://www.wowway.com/~zlinuxman/kernel/postinst.d/initramfs-tools /etc/kernel/postrm.d/initramfs-tools http://www.wowway.com/~zlinuxman/kernel/postrm.d/initramfs-tools For the boot loader hook to initramfs builders: /etc/initramfs/post-update.d/bootloader http://www.wowway.com/~zlinuxman/initramfs/post-update.d/bootloader (This last interface is not currently functional, of course.) How do they look? -- .''`. 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/1920933269.99141.1278000752640.javamail.r...@md01.wow.synacor.com
Re: [DRAFT] Policy for Linux kernel, initramfs, boot loader update process
On Tue, 29 Jun 2010 16:35:40 -0400 (EDT), maximilian attems wrote: On Tue, Jun 29, 2010 at 04:24:48PM -0400, Stephen Powell wrote: Sorry I didn't think of this the first time, but there are up to four steps to preparing a kernel for booting: (1) Installation of the kernel itself (2) Creation of an initial RAM file system (3) Updating symbolic links ... they are deprecated and shouldn't be necessary. there are even more evil incarnations like reverse symlinks or whatever. which we no longer support since longer.. it be better to just get rid of them. Hmm. Well, I don't mind if you drop support for direct symlink maintenance from the kernel maintainer scripts, but the symlinks serve a very useful function: they make it possible for the boot loader configuration file, /etc/lilo.conf, /etc/zipl.conf, etc. to remain a relatively static file. That is how these historic boot loaders, such as lilo and zipl, are used to operating. And remember, on the s390 platform, zipl is the *only* supported boot loader. Since symlinks are not associated with any package in particular, and since they seem to have been designed for the convenience of historic boot loaders such as lilo and zipl, perhaps the best way to handle this is for the boot loader hook script, zz-whatever, to maintain the symlinks, if desired. As a matter of fact, I already have a hook script on hand that does this very thing, and with minor modifications will do nicely, I think. Right now, it unconditionally maintains the symlinks. To generalize it more, it could determine if symlinks already exist or not, and if so where, then maintain them where they are. If the symlinks don't exist, it won't create them. It could also be changed to determine if lilo or zipl is in use, based on the presence of the config file, and invoke the appropriate boot loader. Then, all the maintainer of the s390-tools package would have to do is to include it in the s390-tools package. And the maintainer of lilo could do the same. ... [discussion of initramfs-tools script issues] ... hate those indirections due to debconf magic, but why would the hook scripts need one. thanks for hints, been staying away from debconf for long.. the unconditional is expected and there is a wishlist bug open for that it has not high priority as many things do not work if you don'T use an initramfs. Understood. Since you're obviously very busy, I will submit a version of the initramfs-tools script which I believe will address all these issues. Then you can take pot shots at it. ps if you want the no cc thing set up your mua appropriately. here in d-kernel we do cc. I don't care either way, actually. But when in Rome, do as the Romans do. I included you on the cc list, per the above. -- .''`. 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/1257454917.65146.1277904582236.javamail.r...@md01.wow.synacor.com
Re: [DRAFT] Policy for Linux kernel, initramfs, boot loader update process
On Wed, Jun 30, 2010 at 09:29:42AM -0400, Stephen Powell wrote: Since symlinks are not associated with any package in particular, and since they seem to have been designed for the convenience of historic boot loaders such as lilo and zipl, perhaps the best way to handle this is for the boot loader hook script, zz-whatever, to maintain the symlinks, if desired. Beware that multiple boot loaders might be installed concurrently. If each of them provide a zz- hook script implemented independently, they might handle symlinks differently, leading to surprises. - Jonas -- * Jonas Smedegaard - idealist Internet-arkitekt * Tlf.: +45 40843136 Website: http://dr.jones.dk/ [x] quote me freely [ ] ask before reusing [ ] keep private signature.asc Description: Digital signature
Re: [DRAFT] Policy for Linux kernel, initramfs, boot loader update process
On Wed, 30 Jun 2010 10:00:10 -0400 (EDT), Jonas Smedegaard wrote: On Wed, Jun 30, 2010 at 09:29:42AM -0400, Stephen Powell wrote: ... Since symlinks are not associated with any package in particular, and since they seem to have been designed for the convenience of historic boot loaders such as lilo and zipl, perhaps the best way to handle this is for the boot loader hook script, zz-whatever, to maintain the symlinks, if desired. Beware that multiple boot loaders might be installed concurrently. If each of them provide a zz- hook script implemented independently, they might handle symlinks differently, leading to surprises. dpkg does not prevent multiple boot loaders from being installed concurrently; but this environment is not supported by the various system maintainer scripts of Debian, even today. For example, update-initramfs -u currently checks to see if lilo is installed, and if it is, it runs lilo. But if grub (either version 1 or version 2) is installed also, it issues the following messages: WARNING: grub and lilo installed. Please de-install unused bootloader. It could also test for other boot loaders as well, such as extlinux, but it doesn't. The point is that Debian's maintainer scripts do not support multiple concurrently-installed boot loaders even today. -- .''`. 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/952598886.67029.1277908292511.javamail.r...@md01.wow.synacor.com
Re: [DRAFT] Policy for Linux kernel, initramfs, boot loader update process
On Wed, Jun 30, 2010 at 10:31:32AM -0400, Stephen Powell wrote: On Wed, 30 Jun 2010 10:00:10 -0400 (EDT), Jonas Smedegaard wrote: On Wed, Jun 30, 2010 at 09:29:42AM -0400, Stephen Powell wrote: ... Since symlinks are not associated with any package in particular, and since they seem to have been designed for the convenience of historic boot loaders such as lilo and zipl, perhaps the best way to handle this is for the boot loader hook script, zz-whatever, to maintain the symlinks, if desired. Beware that multiple boot loaders might be installed concurrently. If each of them provide a zz- hook script implemented independently, they might handle symlinks differently, leading to surprises. dpkg does not prevent multiple boot loaders from being installed concurrently; but this environment is not supported by the various system maintainer scripts of Debian, even today. For example, update-initramfs -u currently checks to see if lilo is installed, and if it is, it runs lilo. But if grub (either version 1 or version 2) is installed also, it issues the following messages: WARNING: grub and lilo installed. Please de-install unused bootloader. It could also test for other boot loaders as well, such as extlinux, but it doesn't. The point is that Debian's maintainer scripts do not support multiple concurrently-installed boot loaders even today. I read above as initramfs-tools in particular not supporting multiple bootloaders. Could you perhaps elaborate more on why this is a general problem? Kind regards, - Jonas -- * Jonas Smedegaard - idealist Internet-arkitekt * Tlf.: +45 40843136 Website: http://dr.jones.dk/ [x] quote me freely [ ] ask before reusing [ ] keep private signature.asc Description: Digital signature
Re: [DRAFT] Policy for Linux kernel, initramfs, boot loader update process
On Wed, Jun 30, 2010 at 10:31:32AM -0400, Stephen Powell wrote: dpkg does not prevent multiple boot loaders from being installed concurrently; but this environment is not supported by the various system maintainer scripts of Debian, even today. For example, update-initramfs -u currently checks to see if lilo is installed, and if it is, it runs lilo. But if grub (either version 1 or version 2) is installed also, it issues the following messages: WARNING: grub and lilo installed. Please de-install unused bootloader. It could also test for other boot loaders as well, such as extlinux, but it doesn't. The point is that Debian's maintainer scripts do not support multiple concurrently-installed boot loaders even today. It did support it, but it turned out to be a greater pain to keep that then to kick that support, see cc33aa5bfb7f68793 in initramfs-tools git repo for the support that was there until lenny. bug #574553 axed it. support was fragile and thus I don't plan to reinstate that. extlinux is quite new in debian. the usual case were people having upgraded from lilo to grub but didn't change the do_bootloader setting in /etc/kernel-img.conf, because they didn't knew it. -- 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/20100630143154.gn9...@baikonur.stro.at
Re: [DRAFT] Policy for Linux kernel, initramfs, boot loader update process
On Wed, 30 Jun 2010 10:54:53 -0400 (EDT), Jonas Smedegaard wrote: On Wed, Jun 30, 2010 at 10:31:32AM -0400, Stephen Powell wrote: dpkg does not prevent multiple boot loaders from being installed concurrently; but this environment is not supported by the various system maintainer scripts of Debian, even today. For example, update-initramfs -u currently checks to see if lilo is installed, and if it is, it runs lilo. But if grub (either version 1 or version 2) is installed also, it issues the following messages: WARNING: grub and lilo installed. Please de-install unused bootloader. It could also test for other boot loaders as well, such as extlinux, but it doesn't. The point is that Debian's maintainer scripts do not support multiple concurrently-installed boot loaders even today. I read above as initramfs-tools in particular not supporting multiple bootloaders. Could you perhaps elaborate more on why this is a general problem? I think Max has answered that question, as least as it pertains to initramfs-tools. To generalize from that, it makes it difficult for various tools to know what to do or to co-ordinate with each other. For example, only one boot loader can own the master boot record. So if two hook scripts starting with zz- are installed, one for each boot loader, what happens? The last one to execute wins? That's not going to work. Let's turn that question around. What legitimate purpose is served by having multiple concurrently-installed boot loaders? -- .''`. 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/459396134.69046.1277911907155.javamail.r...@md01.wow.synacor.com
Re: [DRAFT] Policy for Linux kernel, initramfs, boot loader update process
On Mon, 28 Jun 2010 19:07:16 -0400 (EDT), Ben Hutchings wrote: Please reply to debian-kernel only. As you wish. I had reason to believe that some key players were probably not subscribed to debian-kernel. But they are now at least aware of the thread and can follow it further if they so desire. I have now subscribed to debian-kernel myself; so there is no need to CC me. 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. OK. [...] 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. That's good. 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. That's a good idea. I'm just concerned about migrations from a previous release where users may be relying on the implicit default to get their boot loader run. 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. OK. -- .''`. 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/1129698791.34865.1277816465356.javamail.r...@md01.wow.synacor.com
Re: [DRAFT] Policy for Linux kernel, initramfs, boot loader update process
On Mon, 28 Jun 2010 19:07:16 -0400 (EDT), Ben Hutchings wrote: ... 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. Sorry I didn't think of this the first time, but there are up to four steps to preparing a kernel for booting: (1) Installation of the kernel itself (2) Creation of an initial RAM file system (3) Updating symbolic links (4) Running the boot loader installer Not all steps are required in all cases, depending on the circumstances. Neither grub version 1 nor grub version 2 generally use symbolic links; so that hasn't been on the forefront of most people's minds. Strictly speaking, the historic boot loaders such as lilo and zipl don't *have* to use symbolic links, but as they have historically been used in Debian systems, they generally do. Obviously, item 1 takes care of itself. For stock kernels, item 2 also takes care of itself. And it appears that the latest version of initramfs-tools provides hook scripts of the same name in /etc/kernel/postinst.d and /etc/kernel/postrm.d which take care of item 2 for kernel image packages created by make-kpkg and make deb-pkg as well. (Actually, that item does need some work, but I'll come back to that later. For now, let's assume that item 2 is taken care of.) Item 4 is what we've been talking about. Each boot loader that needs some kind of update will have to provide a hook script starting with zz-. Now the question is, what should we do about item 3, maintaining the symlinks? For stock kernels, that has historically been handled by variables in /etc/kernel-img.conf: do_symlinks, relative_links, and link_in_boot, mainly, though there are other seldom-used variations. But you just said that the goal was to be able to eliminate /etc/kernel-img.conf. So what do we do about symlinks? Fortunately, the update-initramfs -u issue doesn't affect the symlinks. The symlinks only need to be maintained, if at all, when a kernel is installed, updated, or removed. The symlinks are not, strictly speaking, associated with a package. Should the boot loader script take care of it? Or should this be a separate script? What do you think? I said I would come back to initramfs-tools; so now I'm back. There are two issues with the script as written today. (1) it does not redirect standard output to standard error when invoking update-initramfs. Thus, the user sees no output (since debconf swallows it) and, depending on the output, it may cause problems for debconf. (2) it unconditionally creates an initial RAM file system for kernel image packages created by make-kpkg, even if the user doesn't want one. There is a way to check to see if one is needed. I can submit a revised version of the script if you like. Would you like me to do so? -- .''`. 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/1783519414.48436.1277843088409.javamail.r...@md01.wow.synacor.com
Re: [DRAFT] Policy for Linux kernel, initramfs, boot loader update process
On Tue, Jun 29, 2010 at 04:24:48PM -0400, Stephen Powell wrote: On Mon, 28 Jun 2010 19:07:16 -0400 (EDT), Ben Hutchings wrote: ... 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. Sorry I didn't think of this the first time, but there are up to four steps to preparing a kernel for booting: (1) Installation of the kernel itself (2) Creation of an initial RAM file system (3) Updating symbolic links they are deprecated and shouldn't be necessary. there are even more evil incarnations like reverse symlinks or whatever. which we no longer support since longer.. it be better to just get rid of them. (4) Running the boot loader installer Not all steps are required in all cases, depending on the circumstances. Neither grub version 1 nor grub version 2 generally use symbolic links; so that hasn't been on the forefront of most people's minds. Strictly speaking, the historic boot loaders such as lilo and zipl don't *have* to use symbolic links, but as they have historically been used in Debian systems, they generally do. Obviously, item 1 takes care of itself. For stock kernels, item 2 also takes care of itself. And it appears that the latest version of initramfs-tools provides hook scripts of the same name in /etc/kernel/postinst.d and /etc/kernel/postrm.d which take care of item 2 for kernel image packages created by make-kpkg and make deb-pkg as well. (Actually, that item does need some work, but I'll come back to that later. For now, let's assume that item 2 is taken care of.) Item 4 is what we've been talking about. Each boot loader that needs some kind of update will have to provide a hook script starting with zz-. Now the question is, what should we do about item 3, maintaining the symlinks? For stock kernels, that has historically been handled by variables in /etc/kernel-img.conf: do_symlinks, relative_links, and link_in_boot, mainly, though there are other seldom-used variations. But you just said that the goal was to be able to eliminate /etc/kernel-img.conf. So what do we do about symlinks? Fortunately, the update-initramfs -u issue doesn't affect the symlinks. The symlinks only need to be maintained, if at all, when a kernel is installed, updated, or removed. The symlinks are not, strictly speaking, associated with a package. Should the boot loader script take care of it? Or should this be a separate script? What do you think? get rid of them. they are ugly and useless. I said I would come back to initramfs-tools; so now I'm back. There are two issues with the script as written today. (1) it does not redirect standard output to standard error when invoking update-initramfs. Thus, the user sees no output (since debconf swallows it) and, depending on the output, it may cause problems for debconf. (2) it unconditionally creates an initial RAM file system for kernel image packages created by make-kpkg, even if the user doesn't want one. There is a way to check to see if one is needed. I can submit a revised version of the script if you like. Would you like me to do so? hate those indirections due to debconf magic, but why would the hook scripts need one. thanks for hints, been staying away from debconf for long.. the unconditional is expected and there is a wishlist bug open for that it has not high priority as many things do not work if you don'T use an initramfs. thanks ps if you want the no cc thing set up your mua appropriately. here in d-kernel we do cc. -- 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/20100629203540.gh9...@baikonur.stro.at
Re: [DRAFT] Policy for Linux kernel, initramfs, boot loader update process
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-kernel-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
On Mon, 2010-06-28 at 10:45 +0200, maximilian attems wrote: On Mon, 28 Jun 2010, 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 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. I'm wondering whether this is a reasonable way to test whether a kernel package upgrade is in progress. 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. [...] Do you mean that the boot loader might not get updated during a dist-upgrade? I think that even if the kernel or initramfs builder package is installed/upgraded before the boot loader package is upgraded to include hook scripts, the boot loader package will update the boot loader when it is upgraded. (And the boot loader package is sure to be upgraded in order to add those hook scripts.) 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
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
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
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-kernel-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
On Mon, Jun 28, 2010 at 01:35:20PM +0100, Ben Hutchings wrote: On Mon, 2010-06-28 at 10:45 +0200, maximilian attems wrote: On Mon, 28 Jun 2010, 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 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. I'm wondering whether this is a reasonable way to test whether a kernel package upgrade is in progress. currently it is easy to tell in /etc/kernel if you are invoked by linux-2.6 as it doesn't define KERNEL_PACKAGE_VERSION. make deb-pkg run-parts invocation doesn't pass at all the second stupid arg. for update-initramfs it shouldn't be necessary as the updates are trigger updated anyway. 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. [...] Do you mean that the boot loader might not get updated during a dist-upgrade? I think that even if the kernel or initramfs builder package is installed/upgraded before the boot loader package is upgraded to include hook scripts, the boot loader package will update the boot loader when it is upgraded. (And the boot loader package is sure to be upgraded in order to add those hook scripts.) yes the bootloader might be Lenny one and thus no hooks to be run. in partial upgrades you get all kind of crazy pathes, thus it is better to handle the previsous distro. -- 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/20100628165728.gc9...@baikonur.stro.at
Re: [DRAFT] Policy for Linux kernel, initramfs, boot loader update process
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-kernel-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
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-kernel-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
On Mon, 2010-06-28 at 18:57 +0200, maximilian attems wrote: On Mon, Jun 28, 2010 at 01:35:20PM +0100, Ben Hutchings wrote: On Mon, 2010-06-28 at 10:45 +0200, maximilian attems wrote: On Mon, 28 Jun 2010, 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 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. I'm wondering whether this is a reasonable way to test whether a kernel package upgrade is in progress. currently it is easy to tell in /etc/kernel if you are invoked by linux-2.6 as it doesn't define KERNEL_PACKAGE_VERSION. make deb-pkg run-parts invocation doesn't pass at all the second stupid arg. OK. Should we say that if the second argument is missing then the absolute path is /boot/vmlinuz-$version or /boot/vmlinux-$version according to architecture convention? for update-initramfs it shouldn't be necessary as the updates are trigger updated anyway. 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. [...] Do you mean that the boot loader might not get updated during a dist-upgrade? I think that even if the kernel or initramfs builder package is installed/upgraded before the boot loader package is upgraded to include hook scripts, the boot loader package will update the boot loader when it is upgraded. (And the boot loader package is sure to be upgraded in order to add those hook scripts.) yes the bootloader might be Lenny one and thus no hooks to be run. in partial upgrades you get all kind of crazy pathes, thus it is better to handle the previsous distro. You're thinking of a system with lilo from lenny and initramfs-tools from squeeze? Yes, I see that would be a problem. How do we keep initramfs-tools working in this case while still allowing newer boot loader packages to avoid redundant updates? Could we say that initramfs-tools mustn't invoke boot loaders directly if /etc/initramfs/post-update.d exists and is non-empty? 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
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
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
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
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
