[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

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 <11333@jpl-devvax.JPL.NASA.GOV>
Manoj Srivastava <srivasta@debian.org> <http://www.debian.org/~srivasta/>  
1024D/BF24424C print 4966 F272 D093 B493 410B  924B 21BA DABB BF24 424C



Reply to: