Bug 386061

Summary:	rc.sysinit doesn't support encrypted device mapper volumes
Product:	[Fedora] Fedora	Reporter:	Chris Snook <csnook>
Component:	initscripts	Assignee:	Bill Nottingham <notting>
Status:	CLOSED DUPLICATE	QA Contact:	Fedora Extras Quality Assurance <extras-qa>
Severity:	high	Docs Contact:
Priority:	low
Version:	8	CC:	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:05:19 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:

Description Chris Snook 2007-11-16 00:32:41 UTC

Description of problem:
The order of operations in rc.sysinit makes it impossible to use cryptsetup over
lvm2 (and presumably also dm-raid and dm-multipath) for boot-critical
filesystems, such as /var.  Ephemeral /tmp and swap volumes work fine over LVM2.
   Manual invocation of cryptsetup over lvm2 works just fine, but is quite
laborious.

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

How reproducible:
100%

Steps to Reproduce:
1. partition a hard drive with a /boot partition and an LVM PV
2. create an LVM VG with an LV for /
3. install F8
4. boot into single-user mode
5. create encrypted luks LV and filesystem for /var and move contents of /var to
that filesystem
6. create appropriate /etc/crypttab entry for the encrypted /var LV
7. create appropriate /etc/fstab entry for /var, using the /dev/mapper/ alias
that cryptsetup creates
  
Actual results:
a. If '1 2' is specified at the end of the /var line in fstab, the boot process
will halt and drop into filesystem repair mode.
b. If '0 0' is specified at the end of the /var line in fstab, /var will not be
mounted, and things will generally not work very well.

Expected results:
/var is mounted properly, as would happen if it were on a partition instead of a
logical volume.

Additional info:
Simply adding another call to init_crypto after LVM setup doesn't fix the
problem.  I'm not yet sure why.

Comment 1 Steve Bonneville 2007-11-28 20:12:54 UTC

I've been seeing the same issue with LVM-based encrypted /home in /etc/fstab.

My LUKS encrypted /home is on /dev/VolGroup00/home, /etc/crypttab decrypts to
/dev/mapper/home.  The encryption was orginally set up using FC6.  I'm seeing
result a) exactly as reported in comment #0; I have not tested the configuration
that got result b) because it's wrong.  :)

The first init_crypto run in /etc/rc.sysinit reports

  Starting disk encryption:       [FAILED]

and I am never prompted to enter a passphrase.  Presumably this is because the
next step is to start LVM, so my encrypted device doesn't exist yet....

The interesting thing I can add is that when I remove the entry for
/dev/mapper/home from /etc/fstab entirely, the second RNG-based run
(supposedly for encrypted swap) DOES prompt me for a LUKS passphrase; this is 
just after the message

  Starting disk encryption using the RNG:

Entering the correct passphrase unlocks the volume and creates the
/dev/mapper/home device, but it's too late for it to be mounted by
anything but the automounter.  We also never get graphical boot back
after this point, if that matters.  

Using autofs is my current work-around for this bug.  I've added an autofs
direct map to automatically mount /home on login, which includes the entry

  /home -fstype=ext3  :/dev/mapper/home

The problem here is that this approach works for /home, but won't work for any
encrypted LVM partitions needed before autofs starts.

Unless I'm missing a non-obvious change to how we configure this, this seems to
be a regression from FC6, where this autofs-based work-around was not needed for
LVM-based encrypted /home.

Comment 2 Charles R. Anderson 2008-04-09 20:05:19 UTC


*** This bug has been marked as a duplicate of 221304 ***