Red Hat Bugzilla – Bug 448129
can't kickstart install on existing volume group with a single encrypted physical volume
Last modified: 2013-01-09 23:42:44 EST
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):
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
3.Try to figure out why it fails by adding 'interactive' to the kickstart file
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!)
2 should have worked just like 1. 3 shouldn't raise exceptions.
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
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
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.
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.
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")
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.
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?
There is a fix in anaconda-220.127.116.11-1, which was built on 11 Nov. Have you tried with a tree including this version?
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.
This should be fixed in anaconda-18.104.22.168-1.
A later anaconda has been tagged for the final release.
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.
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:
Is this still a problem in F11? Partitioning code has been almost entirely rewritten, so this bug may have been fixed.
Installing F-11 worked perfectly, thanks!