Description of problem: I have a setup of md raid6 as a bcache backing device, containing a luks encrypted partition, containing an lvm pv. It gets as far as setting up bcache at boot, but fails to decrypt the luks device Version-Release number of selected component (if applicable): bcache-tools-0-0.13.20130909git.fc20.x86_64 util-linux-2.24-0.1.fc20.x86_64 dracut-config-rescue-033-3.git20130913.fc20.x86_64 dracut-network-033-3.git20130913.fc20.x86_64 dracut-033-3.git20130913.fc20.x86_64 How reproducible: Always Steps to Reproduce: 1. setup lvm on luks on bcache on md raid 6 2. boot 3. Actual results: bcache0 is enabled properly, but the luks volume isn't decrypted, and consequently none of its contents are available. Expected results: all lvm volumes available for mounting at boot Additional info: The luks passphrase is the same as my boot device (a separate ssd, which also contains the bcache cache partition). I'm prompted for that passphrase at boot, and I'd expect it to get reused for the luks-on-bcache volume too. Manually unlocking the volume with: cryptsetup luksOpen /dev/bcache0 luks-$(cryptsetup luksUUID /dev/bcache0) works fine, and all the lvm volumes are activated properly. The system is mostly Fedora 19; I only installed bcache-tools, dracut and util-linux from (and their dependencies) from Fedora 20 updates-testing.
Could you try latest F20 lvm2 as well? That version of lvm2 accepts bcache0 as a PV by default, and I think that this will enable LUKS as well.
Thanks for the suggestion; I installed F20 lvm2 and its dependencies. Unfortunately it didn't help. The layering is: filesystems lvm2 luks bcache md disks My understanding is that this will be assembled from the bottom-up, such that the next layer up is assembled from the one below it according to how the device is probed/labelled/detected. So I wouldn't expect lvm to act on bcache directly at all.
You're right, but lvm2 was worth a try. Will get back on this one later. To be sure: it works without bcache in between?
And another thing: could you check if /etc/crypttab is reflecting the current situation?
Unfortunately, I can't easily test without bcache since the disks are already populated. Good suggestion about crypttab; the bcache0 device was not listed there. I added it and will try a reboot later to see if it fixes/changes things.
OK, fantastic, that seems to have done the trick. So I guess there's no bug here after all?
No bug indeed, thanks for testing bcache-tools.