persistent naming: add ID in addition to UUID
Cryptsetup currently allows "LUKS UUID in the format UUID=<uuid>. Translation to real device name uses symlinks in /dev/disk/by-uuid directory", as quoted from man/cryptsetup.8.
Is there a reason why other persistent block device naming schemes are not supported? I for one would love to use by-id, "a unique name depending on the hardware serial number": https://wiki.archlinux.org/index.php/Persistent_block_device_naming#by-id_and_by-path
I am aware of the difference addressing hardware and LUKS header, but in my use case, I actually *do* want to address hardware in crypttab at al.
Thanks, and keep up the good work!
Signature · 4 lines
ilf Über 80 Millionen Deutsche benutzen keine Konsole. Klick dich nicht weg! -- Eine Initiative des Bundesamtes für Tastaturbenutzung
Quoted 4 lines · ilf
Cryptsetup currently allows "LUKS UUID in the format UUID=<uuid>. Translation to real device name uses symlinks in
/dev/disk/by-uuiddirectory", as quoted from man/cryptsetup.8.
Quoted 8 lines
Is there a reason why other persistent block device naming schemes are not supported? I for one would love to use by-id, "a unique name depending on the hardware serial number":
https://wiki.archlinux.org/index.php/Persistent_block_device_naming#by-id_and_by-pathI am aware of the difference addressing hardware and LUKS header, but in my use case, I actually *do* want to address hardware in crypttab at al.
Since you want to use crypttab anyway, is there any particular reason not to use /dev/disk/by-id/<identifier>? As UUID=<uuid> needs proper symlinks anyway, it is rather a handy shorthand at the commandline.
Quoted 5 lines
Thanks, and keep up the good work!
--
ilf
-Sven
Sven Eschenberg:
Quoted 1 line
Since you want to use crypttab anyway, is there any particular reason not to use /dev/disk/by-id/<identifier>?
You are comlpetely right, that works and I should probably use that.
Quoted 1 line
As UUID=<uuid> needs proper symlinks anyway, it is rather a handy shorthand at the commandline.
Well, the man-page for crypttab(5) in Debian and Derivatives sais, "the UUID is supported as well, using UUID=<luks_uuid>". So adding an ID= option would make this more consistent.
Signature · 4 lines
ilf Über 80 Millionen Deutsche benutzen keine Konsole. Klick dich nicht weg! -- Eine Initiative des Bundesamtes für Tastaturbenutzung
Quoted 4 lines · ilf
Sven Eschenberg:
Quoted 2 lines
Since you want to use crypttab anyway, is there any particular reason not to use /dev/disk/by-id/<identifier>?
Quoted 8 lines
You are comlpetely right, that works and I should probably use that.
Quoted 2 lines
As UUID=<uuid> needs proper symlinks anyway, it is rather a handy shorthand at the commandline.
Well, the man-page for crypttab(5) in Debian and Derivatives sais, "the UUID is supported as well, using UUID=<luks_uuid>". So adding an ID= option would make this more consistent.
Actually I added UUID=<..> to cryptsetup to mainly easily implement scripts doing the similar action as fstab/crypttab UUID= mount. (fstab allows LABEL and UUID but not ID; also LUKS has no label)
Not sure if adding ID is worth to do this, it is really just shortcut to udev symlink. Note that UUID is read from header and has always the same format.
ID can be crazy combination of characters, sometimes even dynamic (not everything is hw-serial based, see DM devices for example). (I remember several bugs for multipath/SCSI devices where hw-based ID contains binary data and must be properly escaped for symlink name...)
Milan
Quoted 11 lines · Milan Broz
Quoted 10 lines · ilf
Sven Eschenberg:
Quoted 3 lines
Since you want to use crypttab anyway, is there any particular reason not
to use /dev/disk/by-id/<identifier>?You are comlpetely right, that works and I should probably use that.
Quoted 2 lines
As UUID=<uuid> needs proper symlinks anyway, it is rather a handy shorthand at the commandline.
Quoted 8 lines
Quoted 3 lines
Well, the man-page for crypttab(5) in Debian and Derivatives sais, "the UUID is supported as well, using UUID=<luks_uuid>". So adding an ID= option would make this more consistent.
Actually I added UUID=<..> to cryptsetup to mainly easily implement scripts doing the similar action as fstab/crypttab UUID= mount. (fstab allows LABEL and UUID but not ID; also LUKS has no label)
Sorry to correct you here, but fstab supports all libblkid properties, which are amongst UUID and LABEL some more (PARTLABEL and PARTUUID for GPT work quite well ;-) ). And even UUID and LABEL need libblkid support, otherwise they won't work in fstab.
Quoted 6 lines
Milan
_______________________________________________
dm-crypt mailing list
[email protected]
http://www.saout.de/mailman/listinfo/dm-crypt
Regards
-Sven
Quoted 5 lines · ilf
Sven Eschenberg:
Quoted 3 lines
Since you want to use crypttab anyway, is there any particular reason not
to use /dev/disk/by-id/<identifier>?
Quoted 8 lines
You are comlpetely right, that works and I should probably use that.
Quoted 2 lines
As UUID=<uuid> needs proper symlinks anyway, it is rather a handy shorthand at the commandline.
Well, the man-page for crypttab(5) in Debian and Derivatives sais, "the UUID is supported as well, using UUID=<luks_uuid>". So adding an ID= option would make this more consistent.
Still, if the man page is correct, cryptsetup only uses the symlink, so once your inode manager screws up, there's no gain in not using the symlink directly. In contrast /etc/fstab (mount and friends) supports UUID (and some more) by exploiting libblkid functionality, thus they do not depend on proper inode creation. In this case it does make a whole lot of sende to use UUID=<UUID> and friends.
Quoted 6 lines
--
ilfÜber 80 Millionen Deutsche benutzen keine Konsole. Klick dich nicht weg!
-- Eine Initiative des Bundesamtes für Tastaturbenutzung
Reagrds
-Sven