Systemd waiting for external crypted disks...

I have an external, encrypted, disk that I periodically connect to the laptop. In order to have some easy to remember name, instead of UUID, I placed an entry in /etc/crypttab:

EXTDISK UUID=a809c218-f828-4149-bd9e-1c352a5f94df none

That way, when I connect disk, it will be automatically named EXTDISK and it will have an entry in /dev/mapper directory. Eventually, it will be mounted under /run/media/<userid>/EXTDISK. Note that there are only three fields in the line, each field separated from the other using space. The last field is passphrase placeholder, but I didn't want to have it written on the disk, so I used keyword none to signal that I want to type it each time the disk is opened.

The problem with this setup is that during  boot procedure, systemd waits for this disk to appear and, since there is no disk, it has to timeout. In system logs there will be messages like the following ones:

Dec 29 13:32:15 w530 systemd: Dependency failed for Cryptography Setup for EXTDISK.
Dec 29 13:32:15 w530 systemd: Dependency failed for dev-mapper-EXTDISK.device.
Dec 29 13:37:27 w530 systemd: Expecting device dev-mapper-EXTDISK.device...

The solution is simple. In newer versions of /etc/crypttab there is nofail option that should be added as a part of the fourth field. Note that, if there are multiple options in the fourth field, they all should be separated using commas and no spaces are allowed there. This option isn't listed in the manual page I linked in the introductory section of the post, so check your local manual page about crypttab.

As a side note, while searching for the solution of this timeout problem, I needed at one point to know which physical devices are beneath luks devices, i.e. my /dev/mapper directory looks like this:

# ls -l /dev/mapper/
total 0
crw-------. 1 root root 10, 236 Dec 29 13:27 control
lrwxrwxrwx. 1 root root       7 Dec 29 13:27 fedora-home -> ../dm-3
lrwxrwxrwx. 1 root root       7 Dec 29 13:27 fedora-root -> ../dm-2
lrwxrwxrwx. 1 root root       7 Dec 29 13:27 fedora-swap -> ../dm-1
lrwxrwxrwx. 1 root root       7 Dec 29 13:27 luks-a2c17ceb-222e-4cd2-3330-24a0a1111b43 -> ../dm-0
lrwxrwxrwx. 1 root root       7 Dec 29 13:27 luks-c7e8d2f7-1114-45c0-333b-fb8444222884 -> ../dm-4

What I was curious about are those two luks symlinks for which I didn't know their physical devices. It turned out its easy to find out, using cryptsetup tool:

# cryptsetup status luks-a2c17ceb-222e-4cd2-3330-24a0a1111b43
/dev/mapper/luks-a2c17ceb-222e-4cd2-3330-24a0a1111b43  is active and is in use.
  type:    LUKS1
  cipher:  aes-xts-plain64
  keysize: 512 bits
  device:  /dev/sda2
  offset:  4096 sectors
  size:    999184384 sectors
  mode:    read/write

So, there is an answer, /dev/sda2.

Partition vs. whole disk and creating encrypted filesystem...

With a new laptop I got a 1T disk which I intend to use as a data disk. So, it will have a single encrypted partition. This is a new disk with a 4K sector size and because of that fdisk tool offers me to start partition on 2048th sector. This is some alignment stuff from the old days of MSDOS, and obviously I don't want to waste disk space for those reasons. You can read more about that on Linux ATA Wiki. Linux is the only OS I'll use with this disk. It is possible to start partition from 63rd sector but if you are using fdisk you'll have to first create a partition and then switch to expert menu (option x) where it is possible to move beginning of the partition from 2048th to 63rd sector (option b).

Now, it is also possible to use the whole disk for a filesystem, without partition table. I found some discussions of pros and cons of this approach. Additional question is if the Fedora will recognize such disks during a boot process. LWM HOWTO also talks about this issue. It seems that everything boils down to the problem if some other tools or operating systems, that expect disk to be partitioned, treat disk as unpartitioned and thus destroy data on it. Also, someone noted possible performance degradation, but this was not confirmed by simple testing (look at the first link I gave), and besides, why would that happen when you use the whole disk? It can not be better aligned, can it? Also, someone used the whole disk for his Gentoo OS and then he had to install GRUB. Since GRUB, during installation, asks you whether you want it to be installed on, e.g. /dev/sda or /dev/sda1, it seems that it isn't important if you don't have partition table. But, I didn't go more deeper in this.

In the end, I decided to use the whole disk, no partitions. This disk will hold a single partition, will have only data on it, it will never be used on anything other than Linux, actually, on anything other than my laptop. So, this is the way I decided to go.

So, from that point on everything was very simple:

1. Encrypt the whole disk

# cryptsetup luksFormat /dev/sdc

WARNING!
========
This will overwrite data on /dev/sdc irrevocably.

Are you sure? (Type uppercase yes): YES
Enter LUKS passphrase:
Verify passphrase:

2. Open crypted disk:

   # cryptsetup luksOpen /dev/sdc cryptodev1
   Enter passphrase for /dev/sdc:

3. Create file system:

# mkfs -t ext4 /dev/mapper/cryptodev1
mke2fs 1.42.5 (29-Jul-2012)
Filesystem label=
OS type: Linux
Block size=4096 (log=2)
Fragment size=4096 (log=2)
Stride=0 blocks, Stripe width=0 blocks
61054976 inodes, 244190134 blocks
12209506 blocks (5.00%) reserved for the super user
First data block=0
Maximum filesystem blocks=4294967296
7453 block groups
32768 blocks per group, 32768 fragments per group
8192 inodes per group
Superblock backups stored on blocks:
        32768, 98304, 163840, 229376, 294912, 819200, 884736, 1605632, 2654208,
        4096000, 7962624, 11239424, 20480000, 23887872, 71663616, 78675968,
        102400000, 214990848

Allocating group tables: done
Writing inode tables: done
Creating journal (32768 blocks): done
Writing superblocks and filesystem accounting information: done

4. Remove reserved blocks (5% by default):

# tune2fs -m 0 /dev/mapper/cryptodev1
tune2fs 1.42.5 (29-Jul-2012)
Setting reserved blocks percentage to 0% (0 blocks)

5. Finally, mount a disk:

# mount /dev/mapper/cryptodev1 /mnt

And that's basically it. When you want to use disk, and it is not mounted, then you first have to open crypted device (step 2) and then you mount newly created file system.

Problem of encrypted hard disks in court...

Well, I already blogged about the problem (the post is in Croatian) of encrypted disks, that is, problem from the law enforcement (and probably by extension, a government's) point of view. The case that motivated me to write that previous post didn't finish yet. Namely, according to the latest news, the defendant in this case must turn in decrypted hard drive. Note that she doesn't have to turn password! The problem seems to be around the question how the Fifth Amendment that prevents self-incrimination applies to this case. This is a very tricky question. The problem is that EFF also took part in this case protecting the rights of users to encrypt their data. But, it is also true that criminals, terrorists and others can prevent law enforcement in their investigations. We'll see how this case develops.

In the end, I'm very confident that in Croatia (and similar countries) this kind of questions are like science fiction, even though they are important and relevant!

Newest developments:

• Judge Orders Child Porn Suspect To Decrypt His Hard Drives