Comment 11 for bug 164044

I haven't written a patch. In my specific situation I am trying to use an encrypted swap (it would be the same for any other partition type) *without* LUKS (and without UUIDs - it doesn't really matter). And current code just freezes the boot process and waits for the timeout (because vol_id can't detect that this bunch of encrypted data represents a swap and therefore always returns error). My problem is only this useless waiting for timeout, because the detection mechanism of a readable device is wrong (uses dev_id that doesn't work on non-LUKS data). My temporary solution until someone will fix and possibly rewrite this code, is to be without swap (what just means no hibernating).

unggnu: No, /dev/mapper/root will get assigned exactly the (LUKS) partition you specified in /etc/crypttab. So you exactly know which container partition this is and also what it contains (different partitions mustn't have same UUIDs). I am always using direct device names, but in the case you described and if you insist on using UUIDs you should set the LUKS UUID in crypttab and make it map to root and than use /dev/mapper/root elsewhere where you want to access the decrypted partition.

After running update-initramfs.sh your Initramfs contains data from crypttab, but if you insist you could also pass it via GRUB as a parameter.