Testing initramfs-tools integration

[Lionel Elie Mamane]

On Sat, Dec 16, 2006 at 04:03:42PM +0100, Max Vozeler wrote:
> On Sat, Dec 16, 2006 at 07:25:42AM +0100, Lionel Elie Mamane wrote:
>> On Sat, Dec 02, 2006 at 04:30:44PM +0100, Max Vozeler wrote:

>>> 1. Following README, I added "INITRAMFS_LOOPAES=auto" to /etc/
>>> initramfs-tools/initramfs.conf and went to do update-initramfs to
>>> get the scripts, tools and everything included. (...) revealed that
>>> the variable INITRAMFS_LOOPAES was not initialized. It seems like
>>> vars from the initramfs.conf are not exported to hook scripts. If
>>> this is correct, should we perhaps try to source the config in the
>>> hook script?

>> I rather suggest we change the instructions to have an explicit export
>> of that setting. I did that in the subversion repository.

> Seems fine; Just a question for my understanding: Does this mean
> one has to include the export in initramfs.conf?

Yes. For maximal compatibility with different /bin/sh implementations,
the export and the setting should be two different commands, the
export last. If you think my wording in the README is unclear, feel
free to improve.

> This could be a confusing difference compared to other settings in
> there.

Somewhat, yes.

>>> 4. During boot there was another warning: "/scripts/local-top/loopaes:
>>> <linenum>: modprobe -q: not found". This appears to be due to the call
>>> to iterate_cipher_module "modprobe -q" "$rootencryption". The shell
>>> tries to execute $1 ("modprobe -q"), cannot find it and returns.

>> That was because IFS is set to ":" in iterate_cipher_module... The way
>> you fixed it is fine, another way would have been to change the call
>> to iterate_cipher_module to:

>>  iterate_cipher_module "modprobe:-q" "$rootencryption"

> Ahh. I didn't think of IFS there. So another way could have been to
> change IFS to ": ", right?

Yeah, to the theoretical detriment of cipher module names with spaces
in them, but... these will like never happen, so it would have been
acceptable.

>>> Lionel, once you feel it is ready and we've fixed at least problem
>>> 1) above, I think we should finally upload to unstable.

>> Too late now for etch now.

> How about we upload this branch to experimental, what do you think?

Yes, that would be a good idea.

> I'm not sure how we'd best go about versioning the branch -
> something like 2.12r-15~exp perhaps, so we can do parallel
> development in sid?

I don't think the Debian tools understand parallel branches in any
sane way. We should rather rename the package and make it conflict
and provide loop-aes-utils. A good new name would be
loop-aes-experimental-utils or something like that.

-- 
Lionel