Re: [dm-crypt] identifying vanilla GPT partitions for encryption

[Arno Wagner <arno@wagner.name>]

I know the work-arounds in the FAQ are akward. The reason is, as
explained in the FAQ (I hope, at least I indended to explain it),
that encrypted swap is a blank partition to the OS, and there is 
nothing that can be done about it, except to make it non-blank.
(This is for classical partitions.)

- blkid fails as it looks inside the partition for a filesystem
  or swap ID. Naturally that is not there.

- If your md identidiers are not stable, then something other than
  mdadm is tampering with them. I had that once with a "rescue"
  CD that renumbered all my md devices by starting them with 
  ids it thought up, despite all these devices being marked as
  "kernel-level autodetection". I had to manually change the numbers 
  back. (The stupidity of some people is staggering.) That was the 
  only instance of md numbers not being stable I had in now about 
  12 years if using them. But note that the UUID of the md device 
  should stay stable even when mistreated in this fashion.


In principle, the GPT UUIDs will be a valid way to deal with this,
but I guess GPT is just to new for all Linux filesystem tools
to be able to deal with it. I found a suggestion to use 
"gdisk" here:

  http://www.linux.com/learn/tutorials/730440-using-the-new-guid-partition-table-in-linux-good-bye-ancient-mbr-

and it claims that the GPT partition IDs can be used in fstab.
I cannot test anything with GPT, I just returned my only GPT
disk to MBR (ex. win8 netbook), because GPT and UEFI just is 
too much hassle at this time and I do not use windows on that
device anyways.

Arno



On Thu, Oct 02, 2014 at 21:05:27 CEST, Boylan, Ross wrote:
> [Note this does not concern coming up with a unique code to identify encrypted partition as a type, the subject of a January thread.]
> 
> In brief, can GPT partition UUIDs be used to identify partitions that will
> be the base for encrypted swap (i.e., no LUKS)?
> 
> Background:
> 
> My crypttab included
> # sda2 appears to lack a UUID
> sda2_crypt /dev/sda2 /dev/urandom cipher=aes-cbc-essiv:sha256,size=256,swap
> sdb2_crypt UUID=d0b3bdf0-8711-4780-a31f-2f296c1fea00 /dev/urandom cipher=aes-cbc-essiv:sha256,size=256,swap
> 
> I added and moved around disks and this led to the wrong sda2 being used
> (a possibility mentioned in the FAQ).  The UUID given for sdb2 does not
> exist, so that device was not created.
> 
> The disks are GPT format, and each GPT partition has a UUID
> (http://en.wikipedia.org/wiki/GUID_Partition_Table#Features).  Is it
> possible to use that?
> 
> Since the partitions are swap they do not have a LUKS header to identify
> them.  The FAQ suggests some work-arounds, but they are a bit awkward and
> seem likely to have some performance penalty.  Also, my md device numbers
> have not been stable through my recent work, which involved alternating
> between old and new version of mdadm and creating new md devices.
> 
> blkid does not report a UUID for the raw partitions, and parted does not
> print one out either.  So I'm a bit baffled how to find it, and also have
> doubts that dm-crypt (or whatever handles crypttab) would be able to use
> the ids even if I found them.
> 
> Thanks.
> Ross Boylan
> _______________________________________________
> dm-crypt mailing list
> dm-crypt@saout.de
> http://www.saout.de/mailman/listinfo/dm-crypt

-- 
Arno Wagner,     Dr. sc. techn., Dipl. Inform.,    Email: arno@wagner.name
GnuPG: ID: CB5D9718  FP: 12D6 C03B 1B30 33BB 13CF  B774 E35C 5FA1 CB5D 9718
----
A good decision is based on knowledge and not on numbers. -- Plato

If it's in the news, don't worry about it.  The very definition of 
"news" is "something that hardly ever happens." -- Bruce Schneier