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.
