No encrypted keyfile for cryptroot in Hardy

Bug #256486 reported by martinp
2
Affects Status Importance Assigned to Milestone
initramfs-tools (Ubuntu)
Invalid
Undecided
Unassigned

Bug Description

Binary package hint: initramfs-tools

From what is currently provided in Hardy there seems to be an inconsistency between handling a cryptroot and crypted devices via crypttab.

By using cryptroot I'm referring to a crypted root (/) which is directly mounted after initializing the kernel.
While calling /etc/init.d/cryptdisks it will call /lib/cryptsetup/cryptdisks.functions and map possible non-block device files to a loopX dev and use them as input source for e.g. a key. even more: an encrypted key.

In crypttab you can provide keyfile for a crypted partition which itself is again crypted. e.g. file file1 is aes-encrypted and therefore must be mounted as block-dev beforehand so it can be used as input-key for a partition.

When using cryptroot while booting the system this does not work. There is no losetup in the cpio-arc and therefore unlocking will fail.
The solution might be something like copying losetup when generating the cpio-arc which is fairly easly:
-> copy_exec /sbin/losetup /sbin

The second thing is to extend the cryptroot script in initramfs with sth like
        loopdev=$(losetup -f 2> /dev/null) || return 1

        losetup "$loopdev" "$src" || return 1
        src="$loopdev"
in case the src is not a block-dev

I have experimented with this but it would be nice to have this integrated with the stream so any updates to the kernel or initramfs will have this change. Otherwise if you forget to patch your cpio-arc your system will be.... errr... b0rked. :)

Thank you

Revision history for this message
Jonathan Compton (jecompton) wrote :

This version of Ubuntu is no longer supported. If it is still an issue in a currently supported version (12.04, 13.04, 14.10), please report a new bug.

Changed in initramfs-tools (Ubuntu):
status: New → Invalid
To post a comment you must log in.
This report contains Public information  
Everyone can see this information.

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.