Description of problem: When loading a kickstart file generated by anaconda with some.. "creative" partitioning/lvm/raid, I get a variable referenced before assignment barf from python, which prevents me from loading the ks.cfg. Version-Release number of selected component (if applicable): "4.4", "nahant", RHEL 4, update 4, whatever floats your boat. How reproducible: Run system-config-kickstart, load included ks.cfg, watch output. I captured stdout and stderr to a file, and I am including it here. # generated by running `system-config-kickstart >& stdout_stderr_ks_config.txt` Traceback (most recent call last): File "/usr/share/system-config-kickstart/kickstartGui.py", line 270, in on_activate_open self.fillData() File "/usr/share/system-config-kickstart/kickstartGui.py", line 304, in fillData self.partition_class.fillData() File "/usr/share/system-config-kickstart/partition.py", line 359, in fillData self.raidWindow.populateRaid(line) File "/usr/share/system-config-kickstart/raidWindow.py", line 273, in populateRaid self.addRaidDeviceToTree(raid_object) File "/usr/share/system-config-kickstart/raidWindow.py", line 183, in addRaidDeviceToTree if device_is_valid: UnboundLocalError: local variable 'device_is_valid' referenced before assignment Actual results: Well, clicking "ok" in the window just generates the barf, rather than loading the file as best it can. It also doesn't give me anything meaningful to the display like "hey bozo, you malformed your kickstart file" or similar. I suppose I will have to hunt through the ks.cfg to find out what system-config-kickstart doesn't like. Expected results: I expected it to slurp in the ks.cfg (since anaconda generated it) and configure the default settings in system-config-kickstart so that I could alter things graphically (such as installing from NFS rather than cdrom [note included ks.cfg] etc), rather than toiling at it in vim. Additional info: I was unable to determine version information from system-config-kickstart.py. Giving it --version and -v were both met with python complaints, and the file itself only contains the string "version" twice -- both in the preamble. So, while this is Nahant, or 4.4, or whatever, I'm not sure exactly what version of S-C-K this is compared to what you've got. For what it's worth, system-config-lvm understands all the configuration *applied* to this machine by anaconda (I didn't do it all manually for once), and anaconda didn't crash (even once! hooray!) while I was using disk druid to create the configuration.
Created attachment 137234 [details] this is the "errant" ks.config and associated output
It looks like it doesn't like your raid configuration lines: raid pv.45 --fstype "physical volume (LVM)" --level=RAID1 raid.43 raid.44 raid pv.29 --fstype "physical volume (LVM)" --level=RAID0 raid.27 raid.28 Try changing --level=RAID1 to --level=1 and --level=RAID0 to --level=0 and I think this problem will go away. This is also fixed in Rawhide, and so will be fixed in RHEL5. If you require this fix in an update to RHEL4, please contact your support representative who will raise the issue through the proper channels.
Removing RAID from those lines doesn't seem to change the traceback. I'd enclose another copy of the traceback, but it is entirely identical to the traceback from the first (with "RAID" in place on both lines). For what it's worth, when reading in the "new" config (without RAID on those lines), it looks like the S-C-K utility gets a little further, in that it reads a bunch of LVM partitions, but doesn't get as far as assigning mountpoints or formatting to anything. (this, judging from the output of the saved ks.cfg file after reading in the one it couldn't fully parse) I've been going through the utility manually, and I *think* I can get it to do what I want by entering everything through the main interface. I'm not sure which would take longer -- "fixing" my ks.cfg, or going through all the hassle of doing the "disk druid" stuff in system-config-kickstart (whose interface is somewhat lacking by comparison). Any ideas?