On Sun, 2019-01-13 at 22:31 -0500, brent s. wrote:
On 1/13/19 10:19 PM, brent s. wrote:
Well, unencrypted partition table. What he wants is an encrypted partition table, and more generally no metadata available (so the disk just looks like plain garbage, not x nice labelled partitions with LUKS headers).
also, the LUKS header is still there whether it's on the partition or the whole disk. you're in no way obligated to reveal that information in the GPT's partition type with 7FFEC5C9-2D00-49B7-8941-3EA10A5586B7 identifier. linux doesn't care what the partition type is labeled as, functionally, except to determine auto-raid, unused partitions, and LVM partitions.
OP said they're using plain dm-crypt, however, which *doesn't have* LUKS headers. no matter if it's whole-disk or partition.
the only way you can get around that is with a luksHeaderBackup to a separate source and then a luksHeaderRestore when you want to use it.
but don't take my word for it.
https://gitlab.com/cryptsetup/cryptsetup/wikis/FrequentlyAskedQuestions#5-se...
section 5.2.
No need to use the luksHeaderRestore/luksHeaderBackup. You can create and use a detached LUKS header with the --header parameter. You can use --header, combined with a zero offset on the device and no partition table and it should, in theory, only look like random data across the entire drive. You could then put LVM on the LUKS container for "partitioning." I use a setup like that, though I'm not sure how bootable that setup could be; especially on UEFI systems which require an unencrypted system partition.