Bug 1014778

Summary:	luks on bcache doesn't decrypt
Product:	[Fedora] Fedora	Reporter:	Jeremy Fitzhardinge <jeremy>
Component:	bcache-tools	Assignee:	Rolf Fokkens <rolf>
Status:	CLOSED NOTABUG	QA Contact:	Fedora Extras Quality Assurance <extras-qa>
Severity:	unspecified	Docs Contact:
Priority:	unspecified
Version:	20	CC:	ignatenko, jreznik, rolf
Target Milestone:	---
Target Release:	---
Hardware:	Unspecified
OS:	Unspecified
Whiteboard:
Fixed In Version:		Doc Type:	Bug Fix
Doc Text:		Story Points:	---
Clone Of:		Environment:
Last Closed:	2013-10-03 06:21:08 UTC	Type:	Bug
Regression:	---	Mount Type:	---
Documentation:	---	CRM:
Verified Versions:		Category:	---
oVirt Team:	---	RHEL 7.3 requirements from Atomic Host:
Cloudforms Team:	---	Target Upstream Version:

Description Jeremy Fitzhardinge 2013-10-02 19:02:49 UTC

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.

Comment 1 Rolf Fokkens 2013-10-02 19:36:07 UTC

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.

Comment 2 Jeremy Fitzhardinge 2013-10-02 19:56:53 UTC

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.

Comment 3 Rolf Fokkens 2013-10-02 21:29:29 UTC

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?

Comment 4 Rolf Fokkens 2013-10-02 22:28:46 UTC

And another thing: could you check if /etc/crypttab is reflecting the current situation?

Comment 5 Jeremy Fitzhardinge 2013-10-02 22:50:42 UTC

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.

Comment 6 Jeremy Fitzhardinge 2013-10-02 22:59:32 UTC

OK, fantastic, that seems to have done the trick. So I guess there's no bug here after all?

Comment 7 Rolf Fokkens 2013-10-03 06:21:08 UTC

No bug indeed, thanks for testing bcache-tools.