Re: partman-crypto
Last week has been a lot busier than I had thought, but I've now
commited a first version of partman-crypto to trunk.
On Mon, Aug 08, 2005 at 01:45:13PM -0400, Joey Hess wrote:
> Max Vozeler wrote:
> > I'm curious though: If I include the loop-aes-$KVERS package in the
> > initrd, would there still be a tie situation, considering that a package
> > which provides loop-modules is already installed? That's what I tried
> > initially and made me believe provides were not working.
>
> I was thinking about this a bit more and it occurred to me that you
> may not be including the special header in your module udeb that the
> installer uses to know what kernel the modules work with. Do you have
> a XB-Kernel-Version: 2.4.27-2-386 header (or similar for the real
> kernel version)?
Thanks for the hint, they didn't have that header.
I've done a test with a XB-Kernel-Version header added. The resulting
.udeb control provides loop-modules and has an entry "kernel-version:
2.6.12-1-386" which matches that of the existing kernel loop-modules
udeb. For some reason, with the package installed in the initrd, the
kernel loop-modules is still getting pulled in.
I do not understand how exactly the mechanism works, but noticed that
/var/lib/dpkg/status doesn't list the kernel-version header. Could it be
that the header is considered when looking at the packages file, but is
not taken into account for installed packages?
This question is mostly "academic", please don't waste time on it :)
The module rename loop.$ko -> loop-aes.$ko in loop-AES module packages
turned out to have several advantages and in the end the packages
probably won't provide loop-modules.
> > > Yes, you can hook in at either prebaseconfig time or you can add a
> > > base-installer hook script. Probably base-installer is the right place
> > > to add the hook.
> >
> > That would be: partman-crypto installs a script into
> > /usr/lib/post-base-installer.d/ and that script determines the target
> > kernel from debconf base-installer/kernel/image, right?
>
> base-installer/kernel/image is only a fallback, you'd probably have to
> look at base-installer/kernel/which-kernel. However, I don't envy you
> the task of converting a kernel image name back into something you can
> use to install your module.
It actually seems quite doable (famous last words :)). The current
version uses kvers=${RET#*-image-}. If I'm not mistaken this should
work and seems to work for meta packages (linux-image-2.6-686) and
specific kernel choices (linux-image-2.6.12-1-686).
The script in full, for reference, is at
packages/partman/partman-crypto/crypto_modules
cheers,
Max
Reply to: