Multidisk btrfs on top of dm-crypt fails to mount at boot

[Adam Smith]

I have an encrypted btrfs multidisk volume on top of several dm-crypt devices (one for each actual drive). On boot, the boot stalls at mountall waiting for devices.

The passkey the devices use is not the same as the key used for the root device (and is actually a file stored on the root device) so they can not be unlocked when initramfs loads, thus initramfs call to 'btrfs device scan' does not pick up these devices.

I have been working around this issue by waiting for the boot to stall, entering manual recovery, running 'btrfs device scan' myself, then exiting the recovery shell which re-runs mountall and succeeds.

Thus bug also prevents you from mounting with the multidevices UUID, as the kernel isn't aware of the disk layout until 'btrfs device scan' is actually run with all the devices accessable.

The critical part of dmesg that shows you're affected by this is:
[ 21.769512] device fsid 0b445e2f-6970-4226-9f8e-1956be720c64 devid 1 transid 164754 /dev/mapper/d1
[ 21.770081] btrfs: disk space caching is enabled
[ 21.771146] btrfs: failed to read the system array on dm-7
[ 21.771369] btrfs: open_ctree failed
[ 27.240635] init: mountall main process (487) terminated with status 2

After entering the recovery shell, running 'btrfs device scan' and exiting back to let boot continue, you get the expected output:
[ 34.467728] device fsid 0b445e2f-6970-4226-9f8e-1956be720c64 devid 4 transid 164754 /dev/dm-4
[ 34.519363] device fsid 0b445e2f-6970-4226-9f8e-1956be720c64 devid 5 transid 164754 /dev/dm-3
[ 34.990713] device fsid 0b445e2f-6970-4226-9f8e-1956be720c64 devid 10 transid 164754 /dev/dm-5
[ 35.006642] device fsid 0b445e2f-6970-4226-9f8e-1956be720c64 devid 13 transid 164754 /dev/dm-6
[ 35.027414] device fsid 0b445e2f-6970-4226-9f8e-1956be720c64 devid 1 transid 164754 /dev/dm-7
[ 35.046848] device fsid 0b445e2f-6970-4226-9f8e-1956be720c64 devid 11 transid 164754 /dev/dm-8
[ 35.058880] device fsid 0b445e2f-6970-4226-9f8e-1956be720c64 devid 12 transid 164754 /dev/dm-9
[ 35.538743] device fsid 0b445e2f-6970-4226-9f8e-1956be720c64 devid 14 transid 164754 /dev/dm-10
[ 39.642564] device fsid 0b445e2f-6970-4226-9f8e-1956be720c64 devid 1 transid 164754 /dev/mapper/d1
[ 39.657594] btrfs: disk space caching is enabled
[ 39.788290] btrfs: no dev_stats entry found for device /dev/dm-10 (devid 14) (OK on first mount after mkfs)
[ 39.788297] btrfs: no dev_stats entry found for device /dev/dm-9 (devid 12) (OK on first mount after mkfs)
[ 39.788303] btrfs: bdev /dev/dm-8 errs: wr 0, rd 0, flush 0, corrupt 0, gen 0
[ 39.788306] btrfs: no dev_stats entry found for device /dev/dm-6 (devid 13) (OK on first mount after mkfs)
[ 39.788310] btrfs: bdev /dev/dm-5 errs: wr 0, rd 0, flush 0, corrupt 0, gen 0
[ 39.788314] btrfs: bdev /dev/dm-3 errs: wr 0, rd 0, flush 0, corrupt 0, gen 0
[ 39.788318] btrfs: bdev /dev/dm-4 errs: wr 0, rd 4, flush 0, corrupt 0, gen 0
[ 39.788322] btrfs: bdev /dev/mapper/d1 errs: wr 0, rd 0, flush 0, corrupt 0, gen 0
[ 60.392156] init: failsafe main process (2458) killed by TERM signal

So, to finalise, multidisk btrfs on top of multiple dm-crypt devices that are only unlocked during the cryptdisks-early stage, not in the initramfs, fail to mount due to no call to 'btrfs device scan' between cryptdisks and mountall.

ProblemType: Bug
DistroRelease: Ubuntu 12.10
Package: btrfs-tools 0.19+20120328-7ubuntu1
ProcVersionSignature: Ubuntu 3.5.0-26.42-generic 3.5.7.6
Uname: Linux 3.5.0-26-generic x86_64
ApportVersion: 2.6.1-0ubuntu10
Architecture: amd64
Date: Sun Mar 24 08:23:51 2013
MarkForUpload: True
ProcEnviron:
 LANGUAGE=en_AU:en
 TERM=xterm
 PATH=(custom, no user)
 LANG=en_AU.UTF-8
 SHELL=/bin/bash
SourcePackage: btrfs-tools
UpgradeStatus: No upgrade log present (probably fresh install)

[Launchpad Janitor (janitor)]

Status changed to 'Confirmed' because the bug affects multiple users.

[Grizzly (sven-witterstein)]

There seems to be a general problem i.e. crc32 (and more) need be in the initrd to enable multi-device or crypted btrfs-es to be mounted. It may helpt to update-initramfs -u after btrfs-entries in the fstab have changed.

Workaround: remove the fs in question from fstab (comment it) and put
btrfs device scan
mount -L <your crypted poolname here> /<your mountpoint>

in /etc/rc.local...