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 --fsoptions="noatime" 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 --fsoptions="noatime"
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?
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("installtype") else: anaconda.id.instClass.setSteps(anaconda) - dispatch.skipStep("findrootparts") + # dispatch.skipStep("findrootparts") if interactive or flags.autostep: dispatch.skipStep("installtype") 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-11.4.1.57-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-11.4.1.59-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: http://fedoraproject.org/wiki/BugZappers/HouseKeeping
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!