Bug 1014778 - luks on bcache doesn't decrypt
luks on bcache doesn't decrypt
Status: CLOSED NOTABUG
Product: Fedora
Classification: Fedora
Component: bcache-tools (Show other bugs)
20
Unspecified Unspecified
unspecified Severity unspecified
: ---
: ---
Assigned To: Rolf Fokkens
Fedora Extras Quality Assurance
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2013-10-02 15:02 EDT by Jeremy Fitzhardinge
Modified: 2013-10-03 02:21 EDT (History)
3 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2013-10-03 02:21:08 EDT
Type: Bug
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)

  None (edit)
Description Jeremy Fitzhardinge 2013-10-02 15:02:49 EDT
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 15:36:07 EDT
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 15:56:53 EDT
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 17:29:29 EDT
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 18:28:46 EDT
And another thing: could you check if /etc/crypttab is reflecting the current situation?
Comment 5 Jeremy Fitzhardinge 2013-10-02 18:50:42 EDT
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 18:59:32 EDT
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 02:21:08 EDT
No bug indeed, thanks for testing bcache-tools.

Note You need to log in before you can comment on or make changes to this bug.