Comment 18 for bug 238163

I have a similar issue with the same cryptsetup warning during update-initramfs stage in attempt to achieve key file authorization for root partition during boot process on 13.04.
cryptsetup Version: 2:1.4.3-4ubuntu2
Linux blackrouter 3.8.0-28-generic #41-Ubuntu SMP Fri Jul 26 16:26:01 UTC 2013 x86_64 x86_64 x86_64 GNU/Linux

root@blackrouter:~# cat /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

sda2_crypt has mount point at /
sdb1_crypt has mount point at /media/storage

Both have only slot 0 with key file, sdb1_crypt mounts automatically during boot as expected, while at the step of updating initramfs image in order to achieve the same procedure for sda2_crypt i get the following warning:

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

Which i suspect means that initiating reboot after this is a bad idea and will lead to "unusable" system. This conclusion comes due to another issue, according to which sdb1_crypt fails to mount with 2 active slots: slot #0 with passphrase and slot #1 with a key file (same crypttab), while cryptsetup should have even 10 (if i remember well) active slots that could be used to mount encrypted device on boot.
The described schemes worked perfect at 12.04 for example.

Should i expect it to work if it was working for me and for another drives in system? I assume yes, why not.