<----- disk ----->
cryptsetup without any GPT or Partition likewise:
<-- cryptsetup header -- data area --->
data area will be exported as /dev/mapper/yourname and /dev/dm-???
<--- data area --->
using parted to create a GPT on the data area (cleartext mapped device)
<--- primary GPT area ---- cleartext data ---- secondary GPT area --->
looking at the whole disk you'll have:
<--- cryptsetup header (cryptbegin)<--- primary GPT --- 'cleartext data'
--- secondary GPT>(cryptend)>
1) As noted the kernel does not handle the GPT inside the crypto area,
as the blockdevice is not physical (See dmesg, the kernel will read the
GPTs on physical disks and tell you so)
2) GPTs always come with a shadow copy at the end of device with inverse
offsetting, no matter if you use fdisk, gptfdisk or parted.
Since partitions ontop of pseudo-blockdevices are not kernel handled and
are harder to manage, this is not recommended in general. There are very
specific exceptions where this makes sense, esp. when you do not use
partitions on pseudoblockdevices but volumemanagers or the like. Still,
harder to manage, esp. when something goes utterly wrong. No fun if you
don't know all the tools components and physical stuff very well.
Recommended and normale mode of operations will be:
<--- primary GPT --- part1<luks header --- fs> --- part2<luks header
---- fs> --- <...> --- partN<luks header --- fs> secondary GPT --->
Advantage, once the kernel sees the physical disk, it will automagically
create device inodes (/dev/[sh]dN). You'd then luksOpen all the N
partitions and then mount all the filesystems. I assume CentOS uses
crypttab, that's where the info about your crypto mappings go. Only
disadvantage is:
You'll have to enter one passphrase per partition. If you don't like
this, check your distribution, some of them have startup code that i.e.
let's you use a single passphrase for a keyring which holds all the
passwords.
As an alternative you can create a single partition create a crypto
mapping and use lvm2 ontop of that to slice. This is however harder to
manage, esp if you don't have the experience and using lvm2 to just
slice a jist is a little bit like using a jackhammer on a needle.
This would roughly look like this:
<--- primary GPT --- crypto header --- <LVM header area --- LV1 <fs> ---
LV2 <fs> ... > --- secondary GPT --->
This is quite similiar to using partition on top of the crypto
container. Except that the tools to read a partiton table on a
pseudoblockdevie which create the necessary mapping are usually not part
of the core system, whereas LVM2 usually comes as part of the core
system. The harder managability and recovery when problems arise are
however important to consider.
Regards
-Sven
P.S.: Sorry for the limited ASCII graphics.
Am 10.02.2017 um 13:58 schrieb Houtchen, Steven:
Thanks for the replies, but I am still a little unsure here...
If I create the LUKS container on a whole block device, I understand it
puts the LUKS header the beginning of the block device. I am using GPT
partition tables. I read that parted puts the partition at the beginning of the
block device also
I tried that scenario, and it seem sto work,,, but here are my questions here.
Once I use luksFormat and luksOpen to "create and open the container", I suppose I need to
run "parted" on the container , which the dev/mapper device . Is that the correct way
to do that? If I do that , why doesn't the GPT partition table collide with the LUKs header info
on the block device? Does the /dev/mapper layer prevent that? Or parted?
SteveH
-----Original Message-----
From: dm-crypt [mailto:dm-crypt-bounces@xxxxxxxx] On Behalf Of Sven Eschenberg
Sent: Friday, February 10, 2017 7:35 AM
To: dm-crypt@xxxxxxxx
Subject: Re: crypetsetup and GPT partitions
Hi,
Am 08.02.2017 um 13:33 schrieb Houtchen, Steven:
Hello,
I am trying to use "crypsetup" setup ant "parted" together.
I want to use "cryptsetup" to encrypt a whole solid state disk,
and then use "parted" to create partitions on it with a GPT partition
table. I have be able to do the first task, but not the second.
Usually partitions are handled directly in the kernel which creates the inodes (well depending on the system there's udev in the equation aswell). Anyhow the kernel only looks at physical devices for that (not pseudoblockdevices like device-mapper targets etc.)
That being said:
This mode of operation is possible, but the kernel won't create blockdevice inodes for the partitions after the dm-crypt blockdevice comes up. It is possible to used specific tools like kpartx IIRC, to get additional dm targets for each of the partitions. Be reminded however, that gpt does have a secondary partition table in the end of the device, which will give you extra fun, when you scale a container holding you partitions.
If you want to save time and trouble you don't want to go this route.
Or vice versa. Create a few partitions, and then optionally
encrypt each one individually. I have be able to do the first
task, but not the second.
This is the typical mode of operation as this removes some critical stuff from the equation. Usually you will create your GPT partitions and then create the cryptomapping and then the filesystems. You are free however to throw in any additional block layer as you wish.
So my question is, is "cryptsetup" compatible with parted and
GPT partition table? Or do need to use something like "lvm2"
to accomplish what I am trying to do?
Yes they are compatible, you can use lvm2 if you wish, but there's no need if you don't use large scale storage with dynamic needs.
I am using CentOS7 with
[root@dts1 ~]# cryptsetup --version
cryptsetup 1.6.7
[root@dts1 ~]#
[root@dts1 ~]# parted --version
parted (GNU parted) 3.1
Copyright (C) 2012 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later
<http://gnu.org/licenses/gpl.html>.
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.
Written by
<http://git.debian.org/?p=parted/parted.git;a=blob_plain;f=AUTHORS>.
[root@dts1 ~]#
Both versions are a little outdated but should work as expected.
Thanks for any help you can give me..
*Steve Houtchen
*Senior Software Engineer
*Curtiss-Wright
*2600 Paramount Place, Suite 200, Fairborn, OH 45324
T: 937.610.5420 | F: 937.252.1465
shoutchen@xxxxxxxxxxxxxxxxx <mailto:shoutchen@xxxxxxxxxxxxxxxxx> |
www.curtisswrightds.com <http://www.curtisswrightds.com/>
_______________________________________________
dm-crypt mailing list
dm-crypt@xxxxxxxx
http://www.saout.de/mailman/listinfo/dm-crypt
Regards
-Sven
_______________________________________________
dm-crypt mailing list
dm-crypt@xxxxxxxx
http://www.saout.de/mailman/listinfo/dm-crypt
_______________________________________________________________________
This e-mail and any files transmitted with it are proprietary and intended solely for the use of the individual or entity to whom they are addressed. If you have reason to believe that you have received this e-mail in error, please notify the sender and destroy this e-mail and any attached files. Please note that any views or opinions presented in this e-mail are solely those of the author and do not necessarily represent those of the Curtiss-Wright Corporation or any of its subsidiaries. Documents attached hereto may contain technology subject to government export regulations. Recipient is solely responsible for ensuring that any re-export, transfer or disclosure of this information is in accordance with applicable government export regulations. The recipient should check this e-mail and any attachments for the presence of viruses. Curtiss-Wright Corporation and its subsidiaries accept no liability for any damage caused by any virus transmitted by this e-mail.
_______________________________________________
dm-crypt mailing list
dm-crypt@xxxxxxxx
http://www.saout.de/mailman/listinfo/dm-crypt
_______________________________________________
dm-crypt mailing list
dm-crypt@xxxxxxxx
http://www.saout.de/mailman/listinfo/dm-crypt
