[dm-crypt] crypt_get_uuid does not work as expected with plain volumes
gmazyland at gmail.com
Mon Jan 21 15:19:07 CET 2013
On 01/21/2013 02:40 PM, .. ink .. wrote:
> Hm. That function is confusing.
> There are two UUIDs in fact
> - on disk (applies only to LUKS)
> - for activated device (aka DM-UUID)
> DM-UUID is constructed from format type, on-disk UUID (if present) and
> activated device name (so you are able to activate e.g. snapshot of LUKS
> even with the same on-disk UUID).
> crypt_get_uuid() was formerly designed to return DM-UUID but apparently I
> mixed up something here (PLAIN prefix should not be visible).
> so crypt_get_uuid() was supposed to return something like one of the below entries?
In some old testing API yes, but not now :)
> [ink at mtz ~]$ ls /dev/disk/by-id/dm-uuid
These are is udev links created from DM_UUID (it is adding dm-uuid prefix)
(and created by generic DM udev rules, you will similar links for LVM, multipath etc).
Anyway, I'll switch crypt_get_uuid() to return only on-disk UUID
IOW it will work for LUKS and VERITY where UUID is persistent.
(I did not found users which rely on this old and confusing behaviour for PLAIN/loopAES devices.)
The rest (DM_UUID handling) is internal for libcryptsetup and will remain hidden.
But just for reference (you should not rely on this, internal for libcryptsetup),
DM-UUID is generated like this
| | ---------------------------------
| | activated device name
| - CRYPT device context type (LUKS1/PLAIN/ etc)
- device managed by cryptsetup (similar to LVM,DMRAID,MPATH prefixes)
For device with on-disk UUID:
| | on-disk UUID activated device name
| - CRYPT device context type (LUKS1/PLAIN/etc)
- device managed by cryptsetup
More information about the dm-crypt