Le 13/07/2018 à 03:13, David Christensen a écrit :
file(1) -- no: 2018-07-12 17:55:01 root@po ~ # file /dev/sda1 /dev/sda1: block special (8/1)
You must add the option -s so that file looks into the special device file contents.
wipefs(8) -- not today (!).
Don't worry, despite its dreadful name, wipefs does not wipe anything without the -a or -o option, it just displays found metadata.
Note that this setup is flawed when using a partition on an SCSI-like disk : the installer writes the device name /dev/sdX which is known to be not persistent (that's why UUIDs are used instead when possible). But a plain dm-crypt device has no header and UUID. It would be more reliable to use the PARTUUID= (synthetic on a DOS-partitioned disk) instead.I have been using /dev/disk/by-id/* successfully for a while, but
Did the installer automatically wrote this in /etc/crypttab or did you replace the original device name ?
/dev/disk/by-partuuid sounds even better -- this will prevent confusion if and when I move partitions or images to other devices.
Beware that unlike a UUID or LABEL, a PARTUUID or PARTLABEL is stored in the partition table, not in the partition data. Also note that a DOS partition table entry does not contain a UUID nor LABEL, and the PARTUUID is artificially built by combining the 32-bit "disk identifier" field in the MBR and the partition number. So if the partition number or the disk identifier changes, the PARTUUID changes.
In short :- if you move the disk contents (including the partition table) to another disk, the PARTUUID is preserved ; - if you move the partition contents to another partition, the PARTUUID is not preserved.
There is a hackish way to add a UUID to a plain dm-crypt partition : write metadata of any kind at the beginning of the partition (ext2, swap, LUKS...) and specify an offset for dm-crypt data beyond the metadata.