Bug 448129 - can't kickstart install on existing volume group with a single encrypted physical volume
can't kickstart install on existing volume group with a single encrypted phys...
Product: Fedora
Classification: Fedora
Component: anaconda (Show other bugs)
All Linux
low Severity low
: ---
: ---
Assigned To: David Lehman
Fedora Extras Quality Assurance
: Reopened
Depends On:
Blocks: F10AnacondaBlocker
  Show dependency treegraph
Reported: 2008-05-23 12:46 EDT by Alexandre Oliva
Modified: 2013-01-09 23:42 EST (History)
1 user (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Last Closed: 2009-07-23 16:26:37 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Attachments (Terms of Use)

  None (edit)
Description Alexandre Oliva 2008-05-23 12:46:20 EDT
Description of problem:
After turning my single-PV volume group into an encrypted device, anaconda would
refuse to use it during a kickstart install, and raise exceptions during
interactive kickstart install.

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

How reproducible:
Every time

Steps to Reproduce:
1.Install Fedora 9 interactively, creating an encrypted physical volume, a
volume group on it, and a few logical volumes in the volume group, including
ext3 filesystems and swap (see kickstart snipped below)
2.Verify that the install is automatable, overwriting some filesystems while
preserving others
3.Try to figure out why it fails by adding 'interactive' to the kickstart file
Actual results:
1. works; 2. fails claiming there isn't room to create the requested
filesystems; 3. does the same if you don't select manual configuration; if you
do choose manual configuration, the moment you click on one of the existing
logical volumes to open the volume group edit screen, anaconda barfs with an
exception.  I did save the exception, but I seem to have lost it while rolling
out Fedora 9 and rawhide 10 onto my home boxes while half-asleep, sorry :-(  

It's unfortunately very difficult for me to duplicate the problem now, because I
went with another configuration (single encrypted logical volume) now on top of
raid.  That works just fine (thanks!)

Expected results:
2 should have worked just like 1.  3 shouldn't raise exceptions.

Additional info:
At some point during my attempts to get it to work, I created the encrypted
device, the physical volume, the volume group and the logical volume by hand. 
It is not absolutely impossible that the exceptions may have been caused by my
own errors (although I did manage to bring it all up by hand), but I *did* run
into the problem in 2 before I started messing around with this stuff by hand.

Here's the disk configuration portion of my kickstart file:

#Disk partitioning information
clearpart --none

volgroup all --noformat

logvol swap --useexisting --fstype swap --name=swap --vgname=all

logvol / --useexisting --fstype ext3 --name=test --vgname=all --fsoptions="noatime"

logvol /l --noformat --fstype ext3 --name=l --vgname=all --fsoptions="noatime"

logvol /l/root --noformat --fstype ext3 --name=stable --vgname=all

part /boot --fstype ext3 --onpart sda2 --fsoptions="noatime"
part /l/root/boot --noformat --fstype ext3 --onpart sda1 --fsoptions="noatime"
#stable part /boot --fstype ext3 --onpart sda1 --fsoptions="noatime"
#stable part /l/root/boot --noformat --fstype ext3 --onpart sda2
Comment 1 Alexandre Oliva 2008-10-02 17:59:25 EDT
No visible change in 10-Beta.  Can't install it at all, for I went back to a fully-encrypted physical volume on raid 1.

Any suggestions?

FWIW, if I stop anaconda and bring up the raid device (which anaconda brings up all right), set up the luks device, then anaconda *will* see the volume group in there, but it will still refuse to install onto it, interactively or not.

Any ideas?
Comment 2 Alexandre Oliva 2008-10-03 15:10:50 EDT
So, I tried explicitly listing the raid components and the encrypted raid device, before the volume group.  The result of that was an exception in cryptodev.py, when it tried to look up the luksUUID of a null device.

That, and the fact that it reported that the VG was in an unknown device and the facts that a non-kickstart install didn't trigger this problem and did present and configure the crypto device correctly, were the hints that something was missing in the kickstart code path.

I found out that the disk detection pass was missing information about crypto devices collected during findrootparts.  That's why a non-kickstart install saw the disks just fine, whereas a kickstart install didn't, even if I brought things up by hand.  Commenting out the line:

--- kickstart.py.orig	2008-10-03 16:00:21.000000000 -0300
+++ kickstart.py	2008-10-03 03:22:46.000000000 -0300
@@ -1164,7 +1164,7 @@ def setSteps(anaconda):
-        dispatch.skipStep("findrootparts")
+        # dispatch.skipStep("findrootparts")
     if interactive or flags.autostep:

enabled me to complete an interactive kickstart install.  Although IIRC it didn't quite use the filesystem information from the ks file (didn't look into why), the other configurations were just what I expected, and it at least enabled me to use the volume group to hold the root filesystem (unlike an earlier interactive attempt, that displayed it but didn't let me edit it at all).

That's as far as I got.  I hope it helps someone more familiar with the code to figure out what's missing, to come up with a proper fix that doesn't drop ks disk configuration information and doesn't stop to ask the user whether to install or upgrade, but that does recognize volume groups in encrypted devices even during kickstart.
Comment 3 Alexandre Oliva 2008-11-16 15:22:44 EST
FWIW, the work around in the provided patch was still required for a kickstart install into existing encrypted volume groups on 10-Preview and newer rawhide composes.  Any chance of an actual fix making 10 final?
Comment 4 David Lehman 2008-11-17 11:11:26 EST
There is a fix in anaconda-, which was built on 11 Nov. Have you tried with a tree including this version?
Comment 5 David Lehman 2008-11-17 12:20:00 EST
I just tried it, and it doesn't work. lvm wants to use the /dev/dm-X parlance to refer to mapped devices it finds. We do not do this because it is dependent upon the order in which mappings are created. So, we have to add some more code to correlate /dev/dm-X to /dev/mapper/$something. I can post an updates.img if you are interested once I have a fix.
Comment 6 Chris Lumens 2008-11-17 16:07:48 EST
This should be fixed in anaconda-
Comment 7 Jesse Keating 2008-11-18 17:54:01 EST
A later anaconda has been tagged for the final release.
Comment 8 Alexandre Oliva 2008-12-04 23:01:20 EST
I've just run into this on F-10 final.  AFAICT, it works when the physical volume is a regular (encrypted) partition, but not when it's an mdraid device.
Comment 9 Bug Zapper 2009-06-09 05:35:34 EDT
This bug appears to have been reported against 'rawhide' during the Fedora 11 development cycle.
Changing version to '11'.

More information and reason for this action is here:
Comment 10 Andy Lindeberg 2009-07-16 17:08:34 EDT
Is this still a problem in F11? Partitioning code has been almost entirely rewritten, so this bug may have been fixed.
Comment 11 Alexandre Oliva 2009-07-23 16:26:37 EDT
Installing F-11 worked perfectly, thanks!

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