I've been setting up a few LUKS encrypted drives and noticed that I've been creating the encrypted disk directly on the 'raw'(?) drive, ie. /dev/sdb, while many examples via google are showing it created on /dev/sdb1

Example using /dev/sdb:

# cryptsetup luksFormat /dev/sdb
# cryptsetup luksOpen /dev/sdb lvm_backup

..and then following on with creating volume groups and logical volumes like so:

# vgcreate vg_backup /dev/mapper/lvm_backup
# lvcreate -l +100%FREE lvm_backup -n backup
# mkfs.ext4 /dev/mapper/vg_backup-backup

and finally mounting the drives.

This leave me with a lsblk looking something like this:

sdb                              8:16   0   2.7T  0 disk  
  lvm_backup (dm-3)            252:3    0   2.7T  0 crypt 
    vg_backup-backup (dm-5)    252:5    0     2T  0 lvm   /backup

In contrast, other lsblk output looks like:

sdb                              8:16   0   2.7T  0 disk  
  sdb1                           #:#     0    2.7T 0 part
    lvm_backup (dm-3)            252:3    0   2.7T  0 crypt 
      vg_backup-backup (dm-5)    252:5    0     2T  0 lvm   /backup

What are the advantages/disadvantages of working directly on the disk (/dev/sdb) vs creating a partition (/dev/sdb1) first?

I'm assuming this is probably somewhat related to: https://serverfault.com/questions/338937/differences-between-dev-sda-and-dev-sda1

1 Answer 1


Offhand, I'm thinking that if your using the entire device (/dev/sdb) and your LUKS header is at the start of the drive, and if some other tool or OS "helpfully" decides that your disk is unformatted with no MBR or GPT, if it were to overwrite your LUKS header that would be bad. If you were using a partition for LUKS then at least a new MBR or GPT wouldn't be as devastating.

You should always backup the LUKS header anyway, as the cryptsetup man page advises too.

And this is what the cryptsetup FAQ says about using "2.2 LUKS on partitions or raw disks? What about RAID?" and it's recommended "2.8 Encryption on top of RAID or the other way round?" (it's long but I'll just paste it, mentions RAID & LVM can greatly complicate things, you may want to rethink using LVM on top of LUKS):

2.2 LUKS on partitions or raw disks? What about RAID?

Also see Item 2.8.

This is a complicated question, and made more so by the availability of RAID and LVM. I will try to give some scenarios and discuss advantages and disadvantages. Note that I say LUKS for simplicity, but you can do all the things described with plain dm-crypt as well. Also note that your specific scenario may be so special that most or even all things I say below do not apply.

Be aware that if you add LVM into the mix, things can get very complicated. Same with RAID but less so. In particular, data recovery can get exceedingly difficult. Only add LVM if you have a really good reason and always remember KISS is what separates an engineer from an amateur. Of course, if you really need the added complexity, KISS is satisfied. But be very sure as there is a price to pay for it. In engineering, complexity is always the enemy and needs to be fought without mercy when encountered.

Also consider using RAID instead of LVM, as at least with the old superblock format 0.90, the RAID superblock is in the place (end of disk) where the risk of it damaging the LUKS header is smallest and you can have your array assembled by the RAID controller (i.e. the kernel), as it should be. Use partition type 0xfd for that. I recommend staying away from superblock formats 1.0, 1.1 and 1.2 unless you really need them.


(1) Encrypted partition: Just make a partition to your liking, and put LUKS on top of it and a filesystem into the LUKS container. This gives you isolation of differently-tasked data areas, just as ordinary partitioning does. You can have confidential data, non-confidential data, data for some specific applications, user-homes, root, etc. Advantages are simplicity as there is a 1:1 mapping between partitions and filesystems, clear security functionality and the ability to separate data into different, independent (!) containers.

Note that you cannot do this for encrypted root, that requires an initrd. On the other hand, an initrd is about as vulnerable to a competent attacker as a non-encrypted root, so there really is no security advantage to doing it that way. An attacker that wants to compromise your system will just compromise the initrd or the kernel itself. The better way to deal with this is to make sure the root partition does not store any critical data and to move that to additional encrypted partitions. If you really are concerned your root partition may be sabotaged by somebody with physical access (who would however strangely not, say, sabotage your BIOS, keyboard, etc.), protect it in some other way. The PC is just not set-up for a really secure boot-chain (whatever some people may claim).

That said, if you want an encrypted root partition, you have to store an initrd with cryptsetup somewhere else. The traditional approach is to have a separate partition under /boot for that. You can also put that initrd on a bootable memory stick, bootable CD or bootable external drive as well. The kernel and Grub typically go to the same location as that initrd. A minimal example what such an initrd can look like is given in Section 9.

(2) Fully encrypted raw block device: For this, put LUKS on the raw device (e.g. /dev/sdb) and put a filesystem into the LUKS container, no partitioning whatsoever involved. This is very suitable for things like external USB disks used for backups or offline data-storage.

(3) Encrypted RAID: Create your RAID from partitions and/or full devices. Put LUKS on top of the RAID device, just if it were an ordinary block device. Applications are just the same as above, but you get redundancy. (Side note as many people seem to be unaware of it: You can do RAID1 with an arbitrary number of components in Linux.) See also Item 2.8.

(4) Now, some people advocate doing the encryption below the RAID layer. That has several serious problems. One is that suddenly debugging RAID issues becomes much harder. You cannot do automatic RAID assembly anymore. You need to keep the encryption keys for the different RAID components in sync or manage them somehow. The only possible advantage is that things may run a little faster as more CPUs do the encryption, but if speed is a priority over security and simplicity, you are doing this wrong anyways. A good way to mitigate a speed issue is to get a CPU that does hardware AES as most do today.

2.8 Encryption on top of RAID or the other way round?

Also see Item 2.2.

Unless you have special needs, place encryption between RAID and filesystem, i.e. encryption on top of RAID. You can do it the other way round, but you have to be aware that you then need to give the passphrase for each individual disk and RAID auto-detection will not work anymore. Therefore it is better to encrypt the RAID device, e.g. /dev/dm0 .

This means that the typical layering looks like this:

  Filesystem     <- top
  Encryption (LUKS)
  Raw partitions (optional)
  Raw disks      <- bottom

The big advantage of this is that you can manage the RAID container just like any other regular RAID container, it does not care that its content is encrypted. This strongly cuts down on complexity, something very valuable with storage encryption.

Try to avoid so-called fake RAID (RAID configured from BIOS but handled by proprietary drivers). Note that some fake RAID firmware automatically writes signature on disks if enabled. This causes corruption of LUKS metadata. Be sure to switch the RAID option off in BIOS if you do not use it.

Another data corruption can happen if you resize (enlarge) the underlying device and some remnant metadata appear near the end of the resized device (like a secondary copy of the GPT table). You can use wipefs command to detect and wipe such signatures.

  • Great, thanks for the info and link! I'm still reading through it but it's actually made me re-think my whole partitioning strategy...now back to the console to re-format and partition!
    – Jonathan
    Jan 10, 2015 at 19:07
  • 1
    You're welcome. That is one problem with all the different options available here, everyone has a different opinion! At least this one is from the "official" cryptsetup FAQ people.
    – Xen2050
    Jan 10, 2015 at 19:48

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .