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-kernel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
