Bug 448129
Summary: | can't kickstart install on existing volume group with a single encrypted physical volume | ||
---|---|---|---|
Product: | [Fedora] Fedora | Reporter: | Alexandre Oliva <oliva> |
Component: | anaconda | Assignee: | David Lehman <dlehman> |
Status: | CLOSED CURRENTRELEASE | QA Contact: | Fedora Extras Quality Assurance <extras-qa> |
Severity: | low | Docs Contact: | |
Priority: | low | ||
Version: | 11 | CC: | dcantrell |
Target Milestone: | --- | Keywords: | Reopened |
Target Release: | --- | ||
Hardware: | All | ||
OS: | Linux | ||
Whiteboard: | |||
Fixed In Version: | Doc Type: | Bug Fix | |
Doc Text: | Story Points: | --- | |
Clone Of: | Environment: | ||
Last Closed: | 2009-07-23 20:26:37 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: | |||
Bug Depends On: | |||
Bug Blocks: | 469046 |
Description
Alexandre Oliva
2008-05-23 16:46:20 UTC
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! |