This service will be undergoing maintenance at 00:00 UTC, 2016-09-28. It is expected to last about 1 hours
Bug 208289 - local variable 'device_is_valid' referenced before assignment
local variable 'device_is_valid' referenced before assignment
Status: CLOSED NEXTRELEASE
Product: Red Hat Enterprise Linux 4
Classification: Red Hat
Component: system-config-kickstart (Show other bugs)
4.4
All Linux
medium Severity medium
: ---
: ---
Assigned To: Chris Lumens
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2006-09-27 14:00 EDT by Alex J. Avriette
Modified: 2010-10-22 02:11 EDT (History)
1 user (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2006-09-27 14:24:48 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:


Attachments (Terms of Use)
this is the "errant" ks.config and associated output (5.01 KB, text/plain)
2006-09-27 14:00 EDT, Alex J. Avriette
no flags Details

  None (edit)
Description Alex J. Avriette 2006-09-27 14:00:19 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.

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.
Comment 1 Alex J. Avriette 2006-09-27 14:00:19 EDT
Created attachment 137234 [details]
this is the "errant" ks.config and associated output
Comment 2 Chris Lumens 2006-09-27 14:24:48 EDT
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.
Comment 3 Alex J. Avriette 2006-09-27 16:09:23 EDT
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?

Note You need to log in before you can comment on or make changes to this bug.