Bug#523735: /etc/kernel/postinst.d/initramfs-tools: please consider supporting the experimental kernel-package out of the box
Why not simply removing that check: # kernel-package passes an extra arg; hack to not run under kernel-package [ -z $2 ] || exit 0 Or are there any reasons (I don't see) why the scripts won't work with kernel-package. One could add a conflict to a too old kernel-package if necessary. Cheers, Chris. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#523735: /etc/kernel/postinst.d/initramfs-tools: please consider supporting the experimental kernel-package out of the box
Hi maks, no it is not the opposite. the hook should *not* be run for linux-images out of linux-2.6 they take care to run update-initramfs in their postinst. those are the official and supported linux images in Debian. Hmm, apparently I've quite misunderstood then. I've always thought that this hook was needed for the official images, but apparently that's not the case. If so, do I understand the following correctly: 1) Official images run update-initramfs themselves. 2) Official images also pass the second argument to the kernel hooks. Probably because of the original comment (# kernel-package passes an extra arg; hack to not run under kernel-package) I thought that 2 was untrue (and thus, 1 as well). But this comment was probably not complete, then. But if the above is true, are there any kernel images that don't pass the second argument? no aboves sentence is wrong (see above) and much too long. I don't quite think that a four line comment can be too long, especially for complicated stuff like this... # Kernel-package passes the path to the vmlinuz file as a second argument, # which might not be in /boot. well that is a strange feature anyway that i don't want to feature too much. I'm not sure how many people will be reading the kernel install hooks, and people who do will probably not start using this just because they can... Gr. Matthijs signature.asc Description: Digital signature
Bug#523735: /etc/kernel/postinst.d/initramfs-tools: please consider supporting the experimental kernel-package out of the box
Hi maks, fixed in latest git, also added 2 small comment lines, which should make code intent clearer, please review happy to add/change them. Hmm, I'm not so sure if this comment helps. The file now says # official linux-images take care themself which would suggest this hook should _not_ run for official images, while it is quite the opposite. I'd write something like: # Don't run for kernels generated by older versions of kernel-package, since # those took care of generating initramfs themselves (but didn't set # KERNEL_PACKAGE_VERSION yet). See #523735. Always run for newer version of # kernel-package and the official Debian kernels. And perhaps a few lines up (where you set bootdir): # Kernel-package passes the path to the vmlinuz file as a second argument, # which might not be in /boot. Gr. Matthijs signature.asc Description: Digital signature
Bug#523735: /etc/kernel/postinst.d/initramfs-tools: please consider supporting the experimental kernel-package out of the box
hello matthijs, On Thu, Oct 01, 2009 at 09:50:18AM +0200, Matthijs Kooijman wrote: fixed in latest git, also added 2 small comment lines, which should make code intent clearer, please review happy to add/change them. Hmm, I'm not so sure if this comment helps. The file now says # official linux-images take care themself which would suggest this hook should _not_ run for official images, while it is quite the opposite. I'd write something like: no it is not the opposite. the hook should *not* be run for linux-images out of linux-2.6 they take care to run update-initramfs in their postinst. those are the official and supported linux images in Debian. homegrown kernel-package build are on their own. but of course in the interest of cooperation this hooks exist also for them. user need to made clear that the easy Debian way of building a linux-image is to unpack a recent linux-2.6 tarball and run make deb-pkg # Don't run for kernels generated by older versions of kernel-package, since # those took care of generating initramfs themselves (but didn't set # KERNEL_PACKAGE_VERSION yet). See #523735. Always run for newer version of # kernel-package and the official Debian kernels. no aboves sentence is wrong (see above) and much too long. And perhaps a few lines up (where you set bootdir): # Kernel-package passes the path to the vmlinuz file as a second argument, # which might not be in /boot. well that is a strange feature anyway that i don't want to feature too much. kind regards maks -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#523735: /etc/kernel/postinst.d/initramfs-tools: please consider supporting the experimental kernel-package out of the box
Hi maks, Done in my local git repo. The next upload of kernel-package, 12.018, will export KERNEL_PACKAGE_VERSION (and also STEM, usually linux) into the environment. Nice. support added, please verify in latest initramfs git, see http://git.debian.org/?p=kernel/initramfs-tools.git I'm not completely sure how the patch works. From how I read it, there are three changes: 1) When ran by kernel-package, and a second argument is passed, use that as the boot dir passed with -b to update-initramfs. This seems like a good idea, but seems unrelated to the main change. 2) When $DEB_MAINT_PARAMS is set, only run if it starts with configure. I'm completely unaware of where this variable comes from and who sets it, but this also seems unrelated (unless the official kernel images and newer kernel-package versions set this, while older versions do not?). 3) The If I'm called by kernel-package, don't run check has been completely removed. This is the main change in the commit, but I think it is a bit stronger than we had discussed (See below). As for the third point, my original proposal was as follows: I propose the following: Let kernel-package expose a KERNEL_PACKAGE_VERSION variable to /etc/kernel/postinst.d scripts. This allows the initramfs-tools script to generate an initrd if a) KERNEL_PACKAGE_VERSION = 12.001 b) KERNEL_PACKAGE_VERSION is not set and there is only a single argument is passed (e.g., for official kernels). The first part (expose KERNEL_PACKAGE_VERSION) was implemented in kernel-package 12.018, but it seems the checks proposed have been removed alltogether. This might be intentional (which means dropping support for kernels generated with kernel-package 12.001)? Actually, we're not even dropping support alltogether, since the only effect would be that update-initramfs is called twice for kernels generated with 12.001. It might even be a good idea, since the alternative (as proposed by me above) would mean still supporting kernel-package 12.001, but breaking kernel-package = 12.001 12.018. On a second reading of the diff, it seems by point 3) above is invalid. The first if clause also contains an exit 0, which causes the update-initramfs to be not run if a second argument is passed but KERNEL_PACKAGE_VERSION is not set (e.g., for kernel-package 12.018). This is pretty much my proposal (just without the = 12.001 version check, but since KERNEL_PACKAGE_VERSION will never be below 12.018, this is the same). However, I've nearly convinced myself that removing the check and always running update-initramfs-tools might be the better approach, since it makes all kernels work out of the box (generating the initramfs twice for 12.001, but that's more acceptable than not generating any for = 12.001 12.018 I think?). So, perhaps we should remove one more check? Manoj? Gr. Matthijs signature.asc Description: Digital signature
Bug#523735: /etc/kernel/postinst.d/initramfs-tools: please consider supporting the experimental kernel-package out of the box
[Snip DEB_MAINT_PARAMS stuff] This is from a proposal initially by Frans Pop, and allows passing through of the maintainer script parameters to the scripts being run. This way, we only build he initramfs when initially configured. This is a good thing. Ah, right. I think I've seen multiple initramfs runs for the same kernel, yes. Nice to have that fixed. I think I would agree with maks here, and let the current code go forward as is. Thiswoud certainly give us consistency for Squeeze, and continue to work as it always did for Lenny backports, and the ongoing support for = 12.001 12.018 generated images is not important enough to spend more time on this. Okay, perfect! The only final comment I'd have is that one or two comments wouldn't look bad in the script, if only to tell any reader why this checking happens (perhaps link to this bug as well). Gr. Matthijs signature.asc Description: Digital signature
Bug#523735: /etc/kernel/postinst.d/initramfs-tools: please consider supporting the experimental kernel-package out of the box
The following message is a courtesy copy of an article that has been posted to gmane.linux.debian.devel.kernel as well. On Wed, Sep 30 2009, Matthijs Kooijman wrote: support added, please verify in latest initramfs git, see http://git.debian.org/?p=kernel/initramfs-tools.git I'm not completely sure how the patch works. From how I read it, there are three changes: 1) When ran by kernel-package, and a second argument is passed, use that as the boot dir passed with -b to update-initramfs. This seems like a good idea, but seems unrelated to the main change. This is indeed very nice. 2) When $DEB_MAINT_PARAMS is set, only run if it starts with configure. I'm completely unaware of where this variable comes from and who sets it, but this also seems unrelated (unless the official kernel images and newer kernel-package versions set this, while older versions do not?). This is from a proposal initially by Frans Pop, and allows passing through of the maintainer script parameters to the scripts being run. This way, we only build he initramfs when initially configured. This is a good thing. 3) The If I'm called by kernel-package, don't run check has been completely removed. This is the main change in the commit, but I think it is a bit stronger than we had discussed (See below). I am not sure I agree. I think this is great -- this adds support for the new kernel-package created kernel images, and has no change for kernel images created by older (11.XX) kernel-package images, which did their own initramfs things. However, I've nearly convinced myself that removing the check and always running update-initramfs-tools might be the better approach, since it makes all kernels work out of the box (generating the initramfs twice for 12.001, but that's more acceptable than not generating any for = 12.001 12.018 I think?). I am not sure. The 11.XX versions of kernel-package are present in a release, while the = 12.001 12.018 have been only in short term development branches. So, perhaps we should remove one more check? Manoj? I think I would agree with maks here, and let the current code go forward as is. Thiswoud certainly give us consistency for Squeeze, and continue to work as it always did for Lenny backports, and the ongoing support for = 12.001 12.018 generated images is not important enough to spend more time on this. manoj -- Keep America beautiful. Swallow your beer cans. Manoj Srivastava sriva...@acm.org http://www.golden-gryphon.com/ 1024D/BF24424C print 4966 F272 D093 B493 410B 924B 21BA DABB BF24 424C -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#523735: /etc/kernel/postinst.d/initramfs-tools: please consider supporting the experimental kernel-package out of the box
Hi maks,
support added, please verify in latest initramfs git, see
http://git.debian.org/?p=kernel/initramfs-tools.git
There's a typo in there, I get:
/etc/kernel/postrm.d/initramfs-tools: line 12: =: command not found
It says:
${bootdir}= $(dirname $2)
which should be:
bootdir=$(dirname $2)
With this change, everything works as expected for me. (I did get a bit
confused,
since something hides the output from the script, including my debug output.
Not sure where or why that happens though)
Gr.
Matthijs
signature.asc
Description: Digital signature
Bug#523735: /etc/kernel/postinst.d/initramfs-tools: please consider supporting the experimental kernel-package out of the box
On Wed, Sep 30, 2009 at 09:36:28PM +0200, Matthijs Kooijman wrote: Hi maks, support added, please verify in latest initramfs git, see http://git.debian.org/?p=kernel/initramfs-tools.git There's a typo in there, I get: thanks indeed for testing! fixed in latest git, also added 2 small comment lines, which should make code intent clearer, please review happy to add/change them. kind regards maks -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#523735: /etc/kernel/postinst.d/initramfs-tools: please consider supporting the experimental kernel-package out of the box
On Sun, 23 Aug 2009, Matthijs Kooijman wrote: Done in my local git repo. The next upload of kernel-package, 12.018, will export KERNEL_PACKAGE_VERSION (and also STEM, usually linux) into the environment. Nice. support added, please verify in latest initramfs git, see http://git.debian.org/?p=kernel/initramfs-tools.git kind regards maks -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#523735: /etc/kernel/postinst.d/initramfs-tools: please consider supporting the experimental kernel-package out of the box
Hi Manoj, I propose the following: Let kernel-package expose a KERNEL_PACKAGE_VERSION variable to /etc/kernel/postinst.d scripts. This allows the initramfs-tools script to generate an initrd if a) KERNEL_PACKAGE_VERSION = 12.001 Or if STEM is set. postinst scripts run by kernel-package image packages have for a long time exported STEM=linux in the environment. I'm not sure what STEM exactly means, but it sounds like the wrong way to detect kernel-package generated kernels to me. You might use it for backwards compatibility perhaps, but using KERNEL_PACKAGE_VERSION seems to me the only proper way (since it explicitly refers to kernel-package, while STEM=linux is just something that happens to be set by kernel-package, but could just as well be set for the official kernels in the future). Done in my local git repo. The next upload of kernel-package, 12.018, will export KERNEL_PACKAGE_VERSION (and also STEM, usually linux) into the environment. Nice. I hope so. In any case, kernel-package is getting behind this proposal. Good. Next up is fixing the initramfs-tools to apply the checks i proposed in my earlier post. Gr. Matthijs signature.asc Description: Digital signature
Bug#523735: /etc/kernel/postinst.d/initramfs-tools: please consider supporting the experimental kernel-package out of the box
On Fri, Jul 03 2009, Matthijs Kooijman wrote: The second argument, which is the location of the kernel image (which need not be in /boot, you know) is used by the scripts shipped with kernel-package to create features that would not be otherwise possible -- unless we also remove from kernel-package the ability to install the image in locations other than /boot. Ah, that makes sense. I guess that the official kernels don't need this parameter because they always install into /boot? That is correct. I propose the following: Let kernel-package expose a KERNEL_PACKAGE_VERSION variable to /etc/kernel/postinst.d scripts. This allows the initramfs-tools script to generate an initrd if a) KERNEL_PACKAGE_VERSION = 12.001 Or if STEM is set. postinst scripts run by kernel-package image packages have for a long time exported STEM=linux in the environment. b) KERNEL_PACKAGE_VERSION is not set and there is only a single argument is passed (e.g., for official kernels). Done in my local git repo. The next upload of kernel-package, 12.018, will export KERNEL_PACKAGE_VERSION (and also STEM, usually linux) into the environment. This will make initramfs-tools, kernel-package and official kernels play together for both new and old versions. The only gap here is kernel-package 12.001 until the current version, which won't work out of the box (but we won't be able to fix those anyway). This approach also allows the initramfs-tools to remove the above checks eventually, when older versions of kernel-package can be considered to be no longer in use. Also, letting kernel-package pass its version to scripts might have other uses as well. It will allow scripts to change their behaviour based on kernel-package version in an elegant way. Even if we were to add kpkg-image-conf like packages later on, these could use the version number as well (because just using Depends: to get the right version won't work, since we might install kernel images built with different versions of kernel-package). Would this work? I hope so. In any case, kernel-package is getting behind this proposal. manoj -- All constants are variables. Manoj Srivastava sriva...@debian.org http://www.debian.org/~srivasta/ 1024D/BF24424C print 4966 F272 D093 B493 410B 924B 21BA DABB BF24 424C -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#523735: /etc/kernel/postinst.d/initramfs-tools: please consider supporting the experimental kernel-package out of the box
Hi Manoj, The second argument, which is the location of the kernel image (which need not be in /boot, you know) is used by the scripts shipped with kernel-package to create features that would not be otherwise possible -- unless we also remove from kernel-package the ability to install the image in locations other than /boot. Ah, that makes sense. I guess that the official kernels don't need this parameter because they always install into /boot? One solution is to have the user deploy scripts into /etc/kernel that meets their needs, but this seems to be somewhat tedious for end users. Yup, that's not really a long-term solution IMHO. A solution might be to create packages that just contain conffiles in /etc/kernel/, and who provide the virtual package kpkg-image-conf, and have all kernel-package image packages Recommend the virtual package. This way, the user will not be impacted by the inability of the initramfs-tools package's conffile to cater to the other flavours of kernel image packages. This sounds rather like a lot of infrastructure for something simple. Also, how would this work with official kernel images? Would this new configfile apply the same second-argument test to only work with kernel-package generated kernels? In that case, we will be stuck forever with two complementary scripts (that essentially do the same) using some ugly hack based om parameter counts to not conflict with each other. Also, in this situation it would be impossible to remove the hack from either script later on. It seems to make more sense to remove the hack from the initramfs-tools script eventually, when the new version of kernel-package has been around for a while. However, until then, we need some other way of making things work, that will transition smoothly into a initramfs-tools script that works for all kernels. I propose the following: Let kernel-package expose a KERNEL_PACKAGE_VERSION variable to /etc/kernel/postinst.d scripts. This allows the initramfs-tools script to generate an initrd if a) KERNEL_PACKAGE_VERSION = 12.001 b) KERNEL_PACKAGE_VERSION is not set and there is only a single argument is passed (e.g., for official kernels). This will make initramfs-tools, kernel-package and official kernels play together for both new and old versions. The only gap here is kernel-package 12.001 until the current version, which won't work out of the box (but we won't be able to fix those anyway). This approach also allows the initramfs-tools to remove the above checks eventually, when older versions of kernel-package can be considered to be no longer in use. Also, letting kernel-package pass its version to scripts might have other uses as well. It will allow scripts to change their behaviour based on kernel-package version in an elegant way. Even if we were to add kpkg-image-conf like packages later on, these could use the version number as well (because just using Depends: to get the right version won't work, since we might install kernel images built with different versions of kernel-package). Would this work? Gr. Matthijs signature.asc Description: Digital signature
Bug#523735: /etc/kernel/postinst.d/initramfs-tools: please consider supporting the experimental kernel-package out of the box
Hi all, I've CC'd Manoj on this, since I am proposing a change in kernel-package to solve this bug. [Summary: Kernel package stopped running update-initramfs, but the initramfs-tools postinst hook specifically doesn't run for kernel-package built kernels] 7c7,10 [ -z $2 ] || exit 0 --- [ -z $2 ] || echo warning: not running update-initramfs, see make-kpkg(1) and /usr/share/doc/kernel-package/README.gz for details exit 0 please use unifiedd diffs, aboves is unreadable. Actually, I think the above is quit readable, if you look at the /etc/kernel/postinst.d/initramfs-tools script. Some extra context would have been useful, though. also aboves is wrong as it would also be called by *official* linux-2.6 produced images. I don't think this is true, since the comment in the script says: # kernel-package passes an extra arg; hack to not run under kernel-package [ -z $2 ] || exit 0 So it seems that this line should really only apply to kernel-package generated kernels (official kernels are no longer generated by kernel-package, according to /usr/share/doc/kernel-package/NEWS.Debian.gz). However, just adding a warning line really won't solve anything. It seems the problem is that the initramfs hook script ignores kernel-package (which it should for older versions), which it shouldn't do for the latest version of kernel-package. However, the script really has no way to tell that the kernel currently installing was built by kernel-package = 12.001. Apparently it can only tell that it was called by kernel-package due to a second argument, which official kernels presumably don't pass? If this is so, what use is the argument anyway, if it's not always passed in? From a kernel-package kernel's postinst script: run-parts --verbose --exit-on-error --arg=$version --arg=$realimageloc$kimage-$version /etc/kernel/postinst.d so it seems it passes some location and version as a second argument, but I can't really tell what. I don't know if the interface for scripts in /etc/kernel/postinst.d is documented anywhere? One obvious solution here, would be to let kernel-package no longer pass in the second argument. This makes it compliant with official kernels, the initramfs-tools can no longer distinguish them, and all should be well. Perhaps Manoj can comment on this? Gr. Matthijs signature.asc Description: Digital signature
Bug#523735: /etc/kernel/postinst.d/initramfs-tools: please consider supporting the experimental kernel-package out of the box
On Thu, Jul 02 2009, Matthijs Kooijman wrote: Hi all, I've CC'd Manoj on this, since I am proposing a change in kernel-package to solve this bug. [Summary: Kernel package stopped running update-initramfs, but the initramfs-tools postinst hook specifically doesn't run for kernel-package built kernels] 7c7,10 [ -z $2 ] || exit 0 --- [ -z $2 ] || echo warning: not running update-initramfs, see make-kpkg(1) and /usr/share/doc/kernel-package/README.gz for details exit 0 please use unifiedd diffs, aboves is unreadable. Actually, I think the above is quit readable, if you look at the /etc/kernel/postinst.d/initramfs-tools script. Some extra context would have been useful, though. also aboves is wrong as it would also be called by *official* linux-2.6 produced images. I don't think this is true, since the comment in the script says: # kernel-package passes an extra arg; hack to not run under kernel-package [ -z $2 ] || exit 0 So it seems that this line should really only apply to kernel-package generated kernels (official kernels are no longer generated by kernel-package, according to /usr/share/doc/kernel-package/NEWS.Debian.gz). However, just adding a warning line really won't solve anything. It seems the problem is that the initramfs hook script ignores kernel-package (which it should for older versions), which it shouldn't do for the latest version of kernel-package. However, the script really has no way to tell that the kernel currently installing was built by kernel-package = 12.001. Apparently it can only tell that it was called by kernel-package due to a second argument, which official kernels presumably don't pass? If this is so, what use is the argument anyway, if it's not always passed in? From a kernel-package kernel's postinst script: run-parts --verbose --exit-on-error --arg=$version --arg=$realimageloc$kimage-$version /etc/kernel/postinst.d so it seems it passes some location and version as a second argument, but I can't really tell what. I don't know if the interface for scripts in /etc/kernel/postinst.d is documented anywhere? There was some discussion about passing in the maintainer script options via the env variable DEB_MAINT_PARAMS (initiated by Frans Pop on the debian-kernel mailing list), but not anything beyond that. One obvious solution here, would be to let kernel-package no longer pass in the second argument. This makes it compliant with official kernels, the initramfs-tools can no longer distinguish them, and all should be well. Perhaps Manoj can comment on this? The second argument, which is the location of the kernel image (which need not be in /boot, you know) is used by the scripts shipped with kernel-package to create features that would not be otherwise possible -- unless we also remove from kernel-package the ability to install the image in locations other than /boot. One solution is to have the user deploy scripts into /etc/kernel that meets their needs, but this seems to be somewhat tedious for end users. A solution might be to create packages that just contain conffiles in /etc/kernel/, and who provide the virtual package kpkg-image-conf, and have all kernel-package image packages Recommend the virtual package. This way, the user will not be impacted by the inability of the initramfs-tools package's conffile to cater to the other flavours of kernel image packages. manoj -- I won't mention any names, because I don't want to get sun4's into trouble... :-) -- Larry Wall in 11...@jpl-devvax.jpl.nasa.gov Manoj Srivastava sriva...@debian.org http://www.debian.org/~srivasta/ 1024D/BF24424C print 4966 F272 D093 B493 410B 924B 21BA DABB BF24 424C -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#523735: /etc/kernel/postinst.d/initramfs-tools: please consider supporting the experimental kernel-package out of the box
Manoj Srivastava sriva...@debian.org writes: On Thu, Jul 02 2009, Matthijs Kooijman wrote: Hi all, I've CC'd Manoj on this, since I am proposing a change in kernel-package to solve this bug. [Summary: Kernel package stopped running update-initramfs, but the initramfs-tools postinst hook specifically doesn't run for kernel-package built kernels] 7c7,10 [ -z $2 ] || exit 0 --- [ -z $2 ] || echo warning: not running update-initramfs, see make-kpkg(1) and /usr/share/doc/kernel-package/README.gz for details exit 0 please use unifiedd diffs, aboves is unreadable. Actually, I think the above is quit readable, if you look at the /etc/kernel/postinst.d/initramfs-tools script. Some extra context would have been useful, though. also aboves is wrong as it would also be called by *official* linux-2.6 produced images. I don't think this is true, since the comment in the script says: # kernel-package passes an extra arg; hack to not run under kernel-package [ -z $2 ] || exit 0 So it seems that this line should really only apply to kernel-package generated kernels (official kernels are no longer generated by kernel-package, according to /usr/share/doc/kernel-package/NEWS.Debian.gz). However, just adding a warning line really won't solve anything. It seems the problem is that the initramfs hook script ignores kernel-package (which it should for older versions), which it shouldn't do for the latest version of kernel-package. However, the script really has no way to tell that the kernel currently installing was built by kernel-package = 12.001. Apparently it can only tell that it was called by kernel-package due to a second argument, which official kernels presumably don't pass? If this is so, what use is the argument anyway, if it's not always passed in? From a kernel-package kernel's postinst script: run-parts --verbose --exit-on-error --arg=$version --arg=$realimageloc$kimage-$version /etc/kernel/postinst.d so it seems it passes some location and version as a second argument, but I can't really tell what. I don't know if the interface for scripts in /etc/kernel/postinst.d is documented anywhere? There was some discussion about passing in the maintainer script options via the env variable DEB_MAINT_PARAMS (initiated by Frans Pop on the debian-kernel mailing list), but not anything beyond that. One obvious solution here, would be to let kernel-package no longer pass in the second argument. This makes it compliant with official kernels, the initramfs-tools can no longer distinguish them, and all should be well. Perhaps Manoj can comment on this? The second argument, which is the location of the kernel image (which need not be in /boot, you know) is used by the scripts shipped with kernel-package to create features that would not be otherwise possible -- unless we also remove from kernel-package the ability to install the image in locations other than /boot. One solution is to have the user deploy scripts into /etc/kernel that meets their needs, but this seems to be somewhat tedious for end users. A solution might be to create packages that just contain conffiles in /etc/kernel/, and who provide the virtual package kpkg-image-conf, and have all kernel-package image packages Recommend the virtual package. This way, the user will not be impacted by the inability of the initramfs-tools package's conffile to cater to the other flavours of kernel image packages. manoj As discussed on irc I like the idea of virtual package for conffile sniplets. But just kpkg-image-conf is to limiting. I suggest to create at least kpkg-image-conf-ramdisk and kpkg-image-conf-bootloader. Kernel images build with --initrd would Depends: kpkg-image-conf-ramdisk and all kernel images would Recommends: kpkg-image-conf-bootloader. Other things are possible as well. That doesn't change the problem though. The problem of having to work with both official Debian kernel images and custom build images. I often had both an official image and my own installed. That MUST be supported. MfG Goswin -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#523735: /etc/kernel/postinst.d/initramfs-tools: please consider supporting the experimental kernel-package out of the box
On Mon, May 04, 2009 at 11:28:24PM -0400, Cipta Herwana wrote: It'll be very helpful if the hook script included with initramfs-tools warns us that it isn't generating the initramfs, as people might not expect it. Something like this: 7c7,10 [ -z $2 ] || exit 0 --- [ -z $2 ] || echo warning: not running update-initramfs, see make-kpkg(1) and /usr/share/doc/kernel-package/README.gz for details exit 0 Cipta please use unifiedd diffs, aboves is unreadable. also aboves is wrong as it would also be called by *official* linux-2.6 produced images. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#523735: /etc/kernel/postinst.d/initramfs-tools: please consider supporting the experimental kernel-package out of the box
It'll be very helpful if the hook script included with initramfs-tools warns us that it isn't generating the initramfs, as people might not expect it. Something like this: 7c7,10 [ -z $2 ] || exit 0 --- [ -z $2 ] || echo warning: not running update-initramfs, see make-kpkg(1) and /usr/share/doc/kernel-package/README.gz for details exit 0 Cipta -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#523735: /etc/kernel/postinst.d/initramfs-tools: please consider supporting the experimental kernel-package out of the box
Package: initramfs-tools Version: 0.93.2 Severity: wishlist File: /etc/kernel/postinst.d/initramfs-tools Since 12.001, kernel-package generated images no longer call any initramfs generating command, instead relying on a postinst hook to do it when necessary. Now, initramfs-tools has such a postinst hook script, but it seems to be (deliberately) ignoring kernel-package kernels. Please change the hook script to handle the new kernel-package kernels, so that I can remove my local hack. -- Package-specific info: -- /proc/cmdline root=/dev/mapper/kukkaseppele-root rootflags=data=journal ro -- /proc/filesystems ext3 ext2 vfat msdos iso9660 udf -- lsmod Module Size Used by option 24228 0 usbserial 33108 1 option snd_hda_codec_realtek 254564 1 snd_hda_codec_si3054 5216 1 snd_hda_intel 28872 0 snd_hda_codec 66944 3 snd_hda_codec_realtek,snd_hda_codec_si3054,snd_hda_intel snd_hwdep 8552 1 snd_hda_codec snd_pcm_oss42880 0 snd_mixer_oss 16832 1 snd_pcm_oss snd_pcm80520 4 snd_hda_codec_si3054,snd_hda_intel,snd_hda_codec,snd_pcm_oss snd_seq_dummy 3044 0 snd_seq_oss33216 0 snd_seq_midi7360 0 snd_rawmidi23168 1 snd_seq_midi snd_seq_midi_event 7232 2 snd_seq_oss,snd_seq_midi snd_seq55968 6 snd_seq_dummy,snd_seq_oss,snd_seq_midi,snd_seq_midi_event snd_timer 22576 2 snd_pcm,snd_seq snd_seq_device 7028 5 snd_seq_dummy,snd_seq_oss,snd_seq_midi,snd_rawmidi,snd_seq snd64584 13 snd_hda_codec_realtek,snd_hda_codec_si3054,snd_hda_intel,snd_hda_codec,snd_hwdep,snd_pcm_oss,snd_mixer_oss,snd_pcm,snd_seq_oss,snd_rawmidi,snd_seq,snd_timer,snd_seq_device soundcore 7552 1 snd snd_page_alloc 9488 2 snd_hda_intel,snd_pcm -- /etc/kernel-img.conf # Kernel image management overrides # See kernel-img.conf(5) for details do_symlinks = yes relative_links = yes do_bootloader = no do_bootfloppy = no warn_initrd = no link_in_boot = no postinst_hook = update-grub postrm_hook = update-grub -- /etc/initramfs-tools/initramfs.conf MODULES=most BUSYBOX=y KEYMAP=n BOOT=local DEVICE=eth0 NFSROOT=auto -- System Information: Debian Release: squeeze/sid APT prefers unstable APT policy: (500, 'unstable'), (500, 'stable'), (1, 'experimental') Architecture: amd64 (x86_64) Kernel: Linux 2.6.29.1-ibid-2-ibid-1 (SMP w/2 CPU cores; PREEMPT) Locale: LANG=fi_FI.UTF-8, LC_CTYPE=fi_FI.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/bash Versions of packages initramfs-tools depends on: ii cpio 2.9.90-3 GNU cpio -- a program to manage ar ii findutils 4.4.0-3utilities for finding files--find, ii klibc-utils 1.5.15-1 small utilities built with klibc f ii module-init-tools 3.7-pre9-1 tools for managing Linux kernel mo ii udev 0.140-2/dev/ and hotplug management daemo Versions of packages initramfs-tools recommends: ii busybox 1:1.10.2-2 Tiny utilities for small and embed initramfs-tools suggests no packages. -- no debconf information -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
