Red Hat Bugzilla – Bug 208289
local variable 'device_is_valid' referenced before assignment
Last modified: 2010-10-22 02:11:34 EDT
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.
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
File "/usr/share/system-config-kickstart/kickstartGui.py", line 304, in fillData
File "/usr/share/system-config-kickstart/partition.py", line 359, in fillData
File "/usr/share/system-config-kickstart/raidWindow.py", line 273, in populateRaid
File "/usr/share/system-config-kickstart/raidWindow.py", line 183, in
UnboundLocalError: local variable 'device_is_valid' referenced before assignment
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
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.
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).