Before filing new bug reports i decided to try to get support on my situation here. Sorry for my english (it may sound frustrating) in advance, feel free to ask about additional details and thanks!! Formatting questions is too complicated, sorry lol, so here is the text version just in case http://paste.ubuntu.com/5967000/

The configuration is as simple as that (no lvm, 2 hdds, no raid):

-> /etc/fstab

# /etc/fstab: static file system information.
# Use 'blkid' to print the universally unique identifier for a
# device; this may be used with UUID= as a more robust way to name devices
# that works even if disks are added and removed. See fstab(5).
# <file system> <mount point>   <type>  <options>       <dump>  <pass>
/dev/mapper/sda2_crypt /               ext4    errors=remount-ro 0       1
# /boot was on /dev/sdc1 during installation
UUID=664ca8af-34b8-4012-ba27-9f48044b6e4e /boot           reiserfs notail          0       2
/dev/mapper/sdb1_crypt /media/storage  ext4    noatime,sync    0       2
/dev/mapper/sda1_crypt none            swap    sw              0       0

-> /etc/crypttab

sda1_crypt /dev/sda1 /dev/urandom cipher=aes-xts-plain64,size=256,swap
sda2_crypt UUID=bc4ff5ca-d27a-423b-9ab1-806b64556ace /boot/key luks
sdb1_crypt UUID=85baac75-dae4-4807-98dd-65d17d0c66f4 /boot/key luks

/dev/sda2 and /dev/sdb1 have one&only Slot0 for /boot/key authorization, which results in:

update-initramfs: Generating /boot/initrd.img-3.8.0-28-generic
cryptsetup: WARNING: target sda2_crypt uses a key file, skipped

and unbootable system.

However, having sda2 with the one&only Slot0 password authorization works flawless meaning automount during boot via luks key file auth for /dev/sdb1

-> /etc/crypttab

sda1_crypt /dev/sda1 /dev/urandom cipher=aes-xts-plain64,size=256,swap
sda2_crypt UUID=bc4ff5ca-d27a-423b-9ab1-806b64556ace none luks
sdb1_crypt UUID=85baac75-dae4-4807-98dd-65d17d0c66f4 /boot/key luks

Getting support related to such configuration appeared to be not that easy, so maybe it's not a bug, because atm i'm not sure about the next moments:

1. Is it necessary to have a keyscript option in order to use luks authorization based on a key file for drive with mount point on / (root fs)?

The question appeared after looking at /usr/share/initramfs-tools/hooks/cryptroot; reading the #13 from https://answers.launchpad.net/ubuntu/+source/cryptsetup/+question/37176 and:

"However, if you wish to make use of more complex setups (such as root‐key‐on‐usb‐memory), you can create a script which does all the steps necessary to retrieve the key and then prints it to stdout." From here /usr/share/doc/cryptsetup/README.initramfs.gz

2. I "can create" it or i "must" in order to mount rootfs using key file?

The situation is totally unclear for me, because:

  • Why i need a keyscript (if i need one) for / device, but not for my /media/storage one? Taking in view my setup with key file for both on removable /boot.

  • Why do i need the key script if it is clear that removable /boot media with the key file is accessible due to the fact that /dev/sdb1 finally comes as mounted luks-mapped device on it's mount point according to /etc/fstab ?

  • If i don't need the keyscript, why i'm getting the warning from initramfs hook which checks if i have one or not for mounting root device? (ending up with unbootable system)

  • If above things are clearly defined , i have the last question: is this a bug or feature? Because it used to work in my previous 12.04 setup as i'm trying to make it work now on freshly installed 13.04, which means that something was fixed leaving me like that or otherwise some feature(s) were added.


# If keyscript is set, the "key" is just an argument to the script
if [ "$key" != "none" ] && [ -z "$KEYSCRIPT" ]; then
    echo "cryptsetup: WARNING: target $target uses a key file, skipped" >&2
    return 1

Does it exist just to make sure i'll get useless warning according to the fact it's != none? Sorry for being so noob.

  • 1
    The last script snippet is clearly a safety check for some misconfigurations. It's very easy to also cover some legitimate (but rare) cases by such safety checks. – Eero Aaltonen Jan 9 '14 at 10:51
  • 2
    I am surprised it took community so long, also i feel guilty for not tracking my own question for so long, but crypttab line should look like that, passdev is a default out-of-box-scenario for such simple purpose: sda1_crypt UUID=your_/_device /dev/disk/by-uuid/_your_whatever_device_which_contains_the_key:/fs/path/to/keyfile luks,keyscript=/lib/cryptsetup/scripts/passdev – n0PxN0p May 25 '14 at 10:18

Your Answer

By clicking "Post Your Answer", you acknowledge that you have read our updated terms of service, privacy policy and cookie policy, and that your continued use of the website is subject to these policies.

Browse other questions tagged or ask your own question.