You are not logged in.
Using the following boot option does not work while using FDE (dm-crypt plain) due to the filesystem being unreachable until decryption.
cryptdevuce=UUID=xxxx-xxxx:root
sda
└ root /
sdb
└ sdb1 /boot
This forces the use of /dev/sda for booting, but occasionally a USB device is mapped to sda instead.
Is there a way to use Persistent Block Device Naming for this type of FDE?
Last edited by easton741 (2015-02-05 01:42:57)
Offline
What exactly is not working? It shouldn't matter if the USB device maps to /dev/sda because the partition with that UUID still resides on the same disk.
Offline
Has been working fine for me for a very long time, but I use luks. On the other hand, you seem to be using something like the uuid of a vfat partition, I don't know if that is how it is with dm-crypt plain but make sure you use the correct uuid.
R00KIE
Tm90aGluZyB0byBzZWUgaGVyZSwgbW92ZSBhbG9uZy4K
Offline
What exactly is not working? It shouldn't matter if the USB device maps to /dev/sda because the partition with that UUID still resides on the same disk.
I guess I should be more clear. The entire sda device is encrypted. This meas that during the initialization there is no UUID is read from the disk because the filesystem cannot be read until it is unencrypted.
This leaves me in a catch 22 where I cannot use UUID until the device is unencrypted, but I need UUID to boot & decrypt the device properly. Here is an example of what the computer sees in the Arch Install.
NAME FSTYPE LABEL UUID MOUNTPOINT
sda
sdb iso9660 ARCH_201501 2015-01-01-09-54-22-00
├─sdb1 iso9660 ARCH_201501 2015-01-01-09-54-22-00 /run/archiso/bootmnt
└─sdb2 vfat ARCHISO_EFI 9051-9287
sdc
└─sdc1 vfat 4EC5-5B7D (normally /boot)
...
As you can see, sda has no uuid.
So I guess what I'm asking is if there is any alternative method because it does not look like I can use anything in the wiki.
Offline
And this is why you always create a partition on a disk. Then you can use PARTLABEL or PARTUUID. Not having a partition table on a disk is a bad idea.
Offline
If you are going for plausible deniability apparently you do in fact want to encrypt the whole disk. Have you tried /dev/disk/by-id/? It isn't perfect, but it may work.
Offline
If you are going for plausible deniability apparently you do in fact want to encrypt the whole disk. Have you tried /dev/disk/by-id/? It isn't perfect, but it may work.
This solution works.
Offline
Do realize that is not a perfect solution since you may have several disks of the same make on the same machine. I, for instance, have three 1TB RE4's and they probably get rearranged in by-id. Just be aware of this limitation.
Also, if you are sure this is a satisfactory solution, please mark this thread as [Solved].
Offline
@nstgc: I've never used by-id, but from looking at the directory I'm curious how it's imperfect and what exactly could get rearranged. For example I have three 250GB RE3s and the ata- entries include the SN. There's also the wwn- entries, and I believe WWNs are assigned by the IEEE and therefore guaranteed to be unique.
But whether the Constitution really be one thing, or another, this much is certain - that it has either authorized such a government as we have had, or has been powerless to prevent it. In either case, it is unfit to exist.
-Lysander Spooner
Offline
Huh, I didn't notice the serial numbers. Good to know. I've never really used them either, preferring more human readable things like by-label. I suppose in that case there is no danger of using by-id aside from getting confused as to what device is what.
Offline