7 thoughts on - LVM Encryption And New Volume Group

• Hi Chris,

  thanks for your answer.

  It is the first time I decided to encrypt my lvm. I choosed to encrypt the volume group, not every logical volume itself, because in case of doing lvm snapshots in that group they will be encrypted too?

  And how do I create a new encrypted volume group?

  Regards Tim

  Am 6. März 2015 01:58:23 MEZ, schrieb Chris Murphy :

• Yes, anything that’s COW’d is also encrypted in this case.

  Strictly speaking the VG isn’t the target of the encryption, the underlying PV is. Also, it’s not absolutely necessary to partition the drive at all if you have no need for unencrypted space on this new drive. Since I use drives on multiple platforms, I always partition so that other OS’s recognize the drive space is spoken for instead of appearing unpartitioned and hence blank. Linux via libblkid always looks at disk contents whether partitioned or not so if this is a Linux only drive you don’t have to partition it.

  1. Use cryptsetup to create a LUKS volume on the whole disk or a partition thereof. For the exact command, you can cheat by doing ‘grep cryptsetup /var/log/anaconda/program.log’ which will show you the command Anaconda used when setting up your first drive. PLEASE make sure you don’t use that command directly or it’ll wipe the LUKS header on your current drive. You have to change the /dev/sdX designation to point to the new drive or partition.

  2 cryptsetup luksOpen /dev/sdX newdrive
  3. pvcreate /dev/mapper/newdrive
  4. vgcreate newvg /dev/mapper/newdrive
  5. lvcreate -L 300G -n morestuff newvg
  6. mkfs.xfs /dev/mapper/newvg-morestuff

  Adapt as needed. Don’t forget crypttab is used to point to the LUKS
  volume, once it’s unlocked the PV is revealed and lvm will activate the VG and the LVs on it, and then in your fstab you’ll have the UUID
  for the XFS volume and mount this whereever you want it mounted.

• You don’t even need to do that. The init scripts try your passphrase on every encrypted volume. If that one passphrase unlocks everything, you’re done. In a graphical boot, you don’t even know which volume you are being prompted to unlock (and the order is not consistent).

• man systemd.special

  cryptsetup.target
  A target that pulls in setup services for all encrypted block devices.

  Hmm. I think it still needs a crypttab entry so this target knows to try to unlock it, and the volumes within need an fstab entry also if you want them automounted.

• I will have a look at the anaconda log. Thanks for the first help. I will have to buy a new Ultrabay case.

  Am 6. März 2015 07:10:31 MEZ, schrieb Chris Murphy :

• I’m sorry, but grep -i crypt /var/log/anaconda/anaconda.program.log returns nothing. But I have got an entry in /etc/crypttab.

  I only found this with grep -i luks /var/log/anaconda/anaconda.*:
  /var/log/anaconda/anaconda.storage.log:20:47:55,959 DEBUG blivet:
  LUKS.__init__:
  /var/log/anaconda/anaconda.storage.log:20:49:25,009 DEBUG storage.ui:
  LUKS.__init__:
  /var/log/anaconda/anaconda.storage.log:20:49:25,009 DEBUG storage.ui:
  getFormat(‘luks’) returning LUKS instance
  /var/log/anaconda/anaconda.storage.log:20:49:25,014 DEBUG storage.ui:
  PartitionDevice._setFormat: sda2 ; current: None ;
  type: luks ;
  /var/log/anaconda/anaconda.storage.log:20:49:25,015 INFO storage.ui:
  registered action: [23] Create Format luks on partition sda2 (id 15)
  /var/log/anaconda/anaconda.storage.log:20:49:25,018 DEBUG storage.ui:
  LUKSDevice._setFormat: luks-sda2 ; current: None ;
  type: lvmpv ;
  /var/log/anaconda/anaconda.storage.log:20:49:25,019 INFO storage.ui:
  added luks/dm-crypt luks-sda2 (id 21) to device tree
  /var/log/anaconda/anaconda.storage.log:20:49:25,019 INFO storage.ui:
  registered action: [24] Create Device luks/dm-crypt luks-sda2 (id 21)
  /var/log/anaconda/anaconda.storage.log:20:49:25,019 INFO storage.ui:
  registered action: [25] Create Format lvmpv on luks/dm-crypt luks-sda2
  (id 21)
  /var/log/anaconda/anaconda.storage.log:20:49:25,020 DEBUG storage.ui:
  LUKSDevice.addChild: kids: 0 ; name: luks-sda2 ;
  …

  Seems as there is no command to crib. :-(

  Regards Tim

  Am 06.03.2015 um 07:10 schrieb Chris Murphy:

• OK ignore what I wrote about crypttab and pointing to a file. Robert’s message is essentially correct.

  It looks like the cryptesetup command gets stripped out of the anaconda.program.log, probably because it contains the user passphrase in it. This is the basic command used in RHEL 7 documentation [1]
  which you can adapt for either a whole disk or partition thereof rather than an LV. cryptsetup –verbose –verify-passphrase luksFormat Just use the same passphrase you’re using for the other drive. Note that the actual key is different for the two LUKS volumes, so you should back up both of those LUKS headers (with cryptsetup), one isn’t enough even though the passphrases are the same. (The DEK used to actually encrypt your data is randomly chosen)

  You’ll need to make the following modifications:

  /etc/fstab mount options for LUKS encrypted volumes includes x-systemd.device-timeout=0 which means it’ll wait indefinitely for this fs volume to appear.

  /etc/crypttab just mimic what’s already there for the existing LUKS
  volume, but of course use the correct UUIDs supplied by blkid.

  /etc/default/grub needs an additional rd.luks.uuid= to make systemd aware to expect it early boot, for example [2]. If you look in the existing /etc/default/grub you’ll see something like:
  GRUB_CMDLINE_LINUX=”rd.luks.uuid=luks-bbf5ebbd-d3f8-425e-9fc4-c48abd23bd8e…. So just add, anywhere in there, another rd.luks.uuid=luks-
  including the uuid for the new luks volume. And then:
  grub2-mkconfig -o /boot/grub2/grub.cfg ##assumes a BIOS system which then creates a new grub.cfg with that addition.

  That should be it. Definitely don’t confuse UUIDs. The LUKS volume has a UUID, and the filesystem on that LUKS volume has its own UUID. They’re not the same thing.

  [1]
  https://access.redhat.com/documentation/en-US/Red_Hat_Enterprise_Linux/7/html/Security_Guide/sec-Encryption.html

  [2]
  [ 0.471569] localhost.localdomain systemd[1]: Expecting device dev-disk-by\x2duuid-cd8dda17\x2d82d2\x2d48d0\x2da1b4\x2d2e68c16a7cc4.device…
  [ 0.471584] localhost.localdomain systemd[1]: Expecting device dev-mapper-luks\x2dcd8dda17\x2d82d2\x2d48d0\x2da1b4\x2d2e68c16a7cc4.device…
  [ 3.255684] localhost.localdomain systemd[1]: Starting Cryptography Setup for luks-cd8dda17-82d2-48d0-a1b4-2e68c16a7cc4…
  [ 9.309257] localhost.localdomain systemd-cryptsetup[264]: Set cipher aes, mode xts-plain64, key size 512 bits for device
  /dev/disk/by-uuid/cd8dda17-82d2-48d0-a1b4-2e68c16a7cc4.
  [ 12.024581] localhost.localdomain systemd[1]: Found device
  /dev/mapper/luks-cd8dda17-82d2-48d0-a1b4-2e68c16a7cc4.
  [ 12.025339] localhost.localdomain systemd[1]: Started Cryptography Setup for luks-cd8dda17-82d2-48d0-a1b4-2e68c16a7cc4.
  [ 12.226048] localhost.localdomain kernel: btrfs: device label CentOS devid 1 transid 39
  /dev/mapper/luks-cd8dda17-82d2-48d0-a1b4-2e68c16a7cc4
  [ 13.701094] localhost.localdomain systemd[1]: Found device
  /dev/mapper/luks-cd8dda17-82d2-48d0-a1b4-2e68c16a7cc4.
  [ 13.727673] localhost.localdomain kernel: btrfs: device label CentOS devid 1 transid 39
  /dev/mapper/luks-cd8dda17-82d2-48d0-a1b4-2e68c16a7cc4