Bug 221304
Summary: | Using LUKS encrypted LVM volumes is broken. | ||||||
---|---|---|---|---|---|---|---|
Product: | [Fedora] Fedora | Reporter: | Jeff Pitman <symbiont> | ||||
Component: | initscripts | Assignee: | Bill Nottingham <notting> | ||||
Status: | CLOSED DUPLICATE | QA Contact: | Brock Organ <borgan> | ||||
Severity: | medium | Docs Contact: | |||||
Priority: | medium | ||||||
Version: | 7 | CC: | cra, csnook, mgarski, opensource, rhare, rvdkleij, rvokal | ||||
Target Milestone: | --- | ||||||
Target Release: | --- | ||||||
Hardware: | All | ||||||
OS: | Linux | ||||||
Whiteboard: | |||||||
Fixed In Version: | Doc Type: | Bug Fix | |||||
Doc Text: | Story Points: | --- | |||||
Clone Of: | Environment: | ||||||
Last Closed: | 2008-04-09 20:30:11 UTC | Type: | --- | ||||
Regression: | --- | Mount Type: | --- | ||||
Documentation: | --- | CRM: | |||||
Verified Versions: | Category: | --- | |||||
oVirt Team: | --- | RHEL 7.3 requirements from Atomic Host: | |||||
Cloudforms Team: | --- | Target Upstream Version: | |||||
Embargoed: | |||||||
Attachments: |
|
Description
Jeff Pitman
2007-01-03 17:55:44 UTC
Created attachment 144722 [details]
Fixes the problem.
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 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) 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. (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. 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. (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? FWIW, if you instead encrypt the PV(s) it should work fine. 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. Right, but that's somewhat non-trivial, not the least of which is because udev doesn't have a user-communication channel. *** Bug 386061 has been marked as a duplicate of this bug. *** *** Bug 227707 has been marked as a duplicate of this bug. *** *** This bug has been marked as a duplicate of 441728 *** @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. |