This is a quick guide for myself, because I forget this too often. Diverge where necessary!

LUKS, btrfs on multiple disks, with systemd

So 10 Sep 12:47:08 JST 2017

The easy part

Make yourself a keyfile: 
		# dd if=/dev/urandom of=/root/filekey bs=1k count=1
		# chmod 400 filekey
Set up LUKS 
		# cryptsetup luksFormat /dev/sda --key-file /root/filekey
		# cryptsetup luksFormat /dev/sdb --key-file /root/filekey
Register the drives in crypttab (get the UUIDs from blkid) 
		media1crypt	UUID="54b76e1d-ce44-4dad-93c4-a8f3030da827"	/root/filekey	luks
		media2crypt	UUID="4d8fe471-1685-4540-844c-d76000911869"	/root/filekey	luks
Add another key in case you lose the keyfile! 
		cryptsetup luksAddKey /dev/sda --key-file /root/filekey
Test 
		# systemctl daemon-reload
		# systemctl start dev-mapper-media1crypt.device dev-mapper-media2crypt.device
Make btrfs 
		# mkfs.btrfs -L buttervolume -f /dev/mapper/media*crypt

The tricky part

The problems start when you want to mount this at boot. Normally, you would simply insert something like 
		/dev/mapper/media1crypt	/media btrfs defaults,…	0	2
into your fstab. However, systemd is not properly aware of the second dependency. (You can actually print the dependency graph and visualize it with graphviz, but that will be horrible.) This dependency can be manually specified using x-systemd.requires. Personally, I use 
		/dev/mapper/media1crypt	/media/volume	btrfs	defaults,noatime,nofail,x-systemd.requires=dev-mapper-media2crypt.device	0	2
To make sure that everything gets properly marked as finished and no startup jobs keep hanging indefinitely, add a udev rule: 
		SUBSYSTEM=="block", ENV{ID_FS_LABEL}=="buttervolume", ENV{SYSTEMD_READY}="1"
Reboot and check that it works as desired: 
		$ mount | column -t

Related

Btrfs Dmcrypt

Trouble shooting

If things don't work out, especially with systemd waiting on devices forever: 

		udevadm info -e
prints the udev state, including the SYSTEMD_READY-state. 
		udevadm trigger
will re-evaluate your udev-rules.

Under ArchLinux ARM, I've noticed a particularly mean thing: if you additionally configure x-systemd.automount, the systemd-fsck service will trigger that automount and consequently hang, because its own check is still pending. I lack complete understanding of how that happened. But deactivating it helped.