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: 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
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
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 fi }
Does it exist just to make sure i'll get useless warning according to the fact it's != none? Sorry for being so noob.