You have the encrypted device referred with either a label or blkid in your fstab.
There is a race condition so that the thread/process waiting for the encrypted filesystem to become available will "catch" the availability event and device before the cryptsetup scripts have time to rename the block device from foo_unformatted to foo. Because the mounting thread is faster, it gets to mount (and lock) the decrypted device while it still has the temporary name.
This is obviously a bug in the startup scripts. A simple workaround would be to refer the block device by its path and not by blkid/label in /etc/fstab. If referred by path, the mounting scripts will wait until the device with path /dev/mapper/foo is available (which will happen only when the cryptsetup scripts get to rename the temporary device)
You have the encrypted device referred with either a label or blkid in your fstab.
There is a race condition so that the thread/process waiting for the encrypted filesystem to become available will "catch" the availability event and device before the cryptsetup scripts have time to rename the block device from foo_unformatted to foo. Because the mounting thread is faster, it gets to mount (and lock) the decrypted device while it still has the temporary name.
This is obviously a bug in the startup scripts. A simple workaround would be to refer the block device by its path and not by blkid/label in /etc/fstab. If referred by path, the mounting scripts will wait until the device with path /dev/mapper/foo is available (which will happen only when the cryptsetup scripts get to rename the temporary device)