Testing initramfs-tools integration

[Lionel Elie Mamane]

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.

> 2. During initramfs generation and boot there was a warning about
> the cipher 'AES128' being unknown; Looking at the code, it seems the
> cipher is passed to decode_cipher with verbatim quotes around it. The
> attached patch gets rid of the warning for me, but probably breaks 
> loading of ciphers which include whitespace. The warning is harmless
> though in that it didn't cause problems for the boot process.

The harmlessness was only because AES128 is a cipher that doesn't need
any additional modules (included in loop.ko), so this warning
announced breakage in some configurations. I have fixed the problem
the right way, re-enabling ciphers with whitespace in their name
again (however improbable their existence is).

> 3. Trying to find the cause for problem 2, I called update-initramfs
> -u a couple of time to update the initramfs. I forgot about problem 1
> and didn't specify INITRAMFS_LOOPAES, so the resulting initramfs didn't
> include loop-AES support. Since I was so clever to do it a few times,
> the backup initramfs (initrd.img-$KVERS.bak) was overwritten too, and 
> on next boot I noticed that I had turned my root partition into a large
> blob of random-looking data as the only place the keyfile was stored 
> now was on the encrypted root partition ;-)

> I think we could do something to help prevent getting systems into
> such a state: README could mention that one should backup the key
> files (and keys, if the keyfile is encrypted asymmetrically)
> somewhere outside the encrypted root partition so that the system
> can still be repaired in case the initramfs gets lost, overwritten
> or some other thing happens to it.

I have added the suggestion that the canonical storage location for
the keys is out of the encrypted partition.

> 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"

or something like the following:

iterate_cipher_module() {
    local cipher
    local IFS=":"
    local ciphers="$1"
    shift
    for cipher in $ciphers; do
       "$@" "loop_${cipher}"
    done
}

...

 iterate_cipher_module "$rootencryption" modprobe -q


So much for trying to emulate functional programming ;-)


> And I feel a bit bad about having so little time currently that
> inclusion was delayed so much.

Oh, well, my available time wasn't very much either.

> 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.

-- 
Lionel