Bug 221304 - Using LUKS encrypted LVM volumes is broken.
Using LUKS encrypted LVM volumes is broken.
Status: CLOSED DUPLICATE of bug 441728
Product: Fedora
Classification: Fedora
Component: initscripts (Show other bugs)
7
All Linux
medium Severity medium
: ---
: ---
Assigned To: Bill Nottingham
Brock Organ
:
: 227707 386061 (view as bug list)
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2007-01-03 12:55 EST by Jeff Pitman
Modified: 2014-03-16 23:04 EDT (History)
7 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2008-04-09 16:30:11 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)
Fixes the problem. (803 bytes, patch)
2007-01-03 12:55 EST, Jeff Pitman
no flags Details | Diff

  None (edit)
Description Jeff Pitman 2007-01-03 12:55:44 EST
Description of problem:

When using an LVM volume group and implementing LUKS encryption on top, init
scripts fail to mount the filesystem because the ordering in rc.sysinit is wrong.

Version-Release number of selected component (if applicable):

8.45.7-1

Steps to Reproduce:
1. Setup LVM groups.
2. Use LUKS to encrypt one of the volumes.
3. mkfs.ext3 on it.
4. reboot
  
Actual results:

Fails to mount and kicks out to maintenance prompt.

Expected results:

Mount properly and ask for password.

Additional info:

The fix is trivially easy. See the included patch. (rc.sysinit.d implementation
would definitely help this.)
Comment 1 Jeff Pitman 2007-01-03 12:55:44 EST
Created attachment 144722 [details]
Fixes the problem.
Comment 2 Till Maas 2007-01-26 15:04:28 EST
I am not sure but isn't this another possible use case that would not work with
your patch?

a) encrypt /dev/sda1 and map it to /dev/mapper/encrypted
b) Use /dev/mapper/encrypted as lvm group
Comment 3 Till Maas 2007-01-29 18:49:13 EST
After discussion with some colleagues whe concluded that the corret way would be
(in pseudocode):

crypto_setup(no random keys)
while(new uninitialzed lvm volumes found) {
lvm_setup()
crypto_setup(no random keys)
}

mount /var...

crypto_setup(with random keys)
Comment 4 Bill Nottingham 2007-06-05 22:04:02 EDT
That's insanely ugly. Calling the same code an indefinite number of times?
There's a reason we no longer do LVM setup twice, and so on. There must be a
better way to do this.
Comment 5 Till Maas 2007-06-06 04:35:09 EDT
(In reply to comment #4)
> That's insanely ugly. Calling the same code an indefinite number of times?

The number of times the code needs to run depends on the system the code runs
on, so there is no number of times that is right for every system. But I guess
more than three iterations are not very often needed.

> There's a reason we no longer do LVM setup twice, and so on. There must be a
> better way to do this.

What is the reason? And I don't think that there is a better way, because the
system cannot know how many lvm volumes there will be, unless the crypto-setup
is done.
Comment 6 Bill Nottingham 2007-06-06 14:03:10 EDT
The reason we don't init lvm twice is because it's silly and wasteful to do so.
A potential solution would be to automatically init crypto on devices as they're
created via udev.
Comment 7 Till Maas 2007-06-08 07:05:33 EDT
(In reply to comment #6)
> The reason we don't init lvm twice is because it's silly and wasteful to do so.

Can one use LVM on a removable device, e.g. an USB-stick? In case it is
possible, how is this managed?

> A potential solution would be to automatically init crypto on devices as they're
> created via udev.

How should the password prompt be displayed to the user in this case?
Comment 8 David Lehman 2007-11-28 14:18:03 EST
FWIW, if you instead encrypt the PV(s) it should work fine.
Comment 9 Roelof van der Kleij 2007-12-24 04:17:51 EST
Just bumped into this one with fedora core 8 while following a draft crypto
howto in the wiki.

I moved the init_crypto run in sysinit.rc for now, but there are more places
where a new filesystem can appear during boot.
I like the "A potential solution would be to automatically init crypto on
devices as they're created via udev." since that represents a generic,
future-proof solution.
Comment 10 Bill Nottingham 2008-01-07 14:37:02 EST
Right, but that's somewhat non-trivial, not the least of which is because udev
doesn't have a user-communication channel.
Comment 11 Charles R. Anderson 2008-04-09 16:05:20 EDT
*** Bug 386061 has been marked as a duplicate of this bug. ***
Comment 12 Charles R. Anderson 2008-04-09 16:05:41 EDT
*** Bug 227707 has been marked as a duplicate of this bug. ***
Comment 13 Bill Nottingham 2008-04-09 16:30:11 EDT

*** This bug has been marked as a duplicate of 441728 ***
Comment 14 Roelof van der Kleij 2008-04-10 03:29:31 EDT
@Bill (sorry for the late response)

IANAP, but as far as I understand the problem you have a chicken and egg problem
here where dmraid, LVM, mdamd, LUKS etc can all be installed on top of each
other in arbitraty sequence. 

I wonder if a crude fix would be to iterate the script. Use a default detection
order which matches the default partitioning scheme (and most normal partition
schemes), and at the end check if everything in /etc/fstab is there. If so,
exit. If not, save the current state and do a second run. Keep iterating untill
either /etc/fstab is complete or nothing new is found between two iterations. In
the latter case, exit with error.




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