Bug 530174

Summary: NameError: global name 'sys' is not defined
Product: [Fedora] Fedora Reporter: Henrik Nordström <henrik>
Component: yumAssignee: Seth Vidal <skvidal>
Status: CLOSED DUPLICATE QA Contact: Fedora Extras Quality Assurance <extras-qa>
Severity: medium Docs Contact:
Priority: medium    
Version: rawhideCC: ffesti, james.antill, john.mellor, maxamillion, pmatilai, tim.lauridsen, vanmeeuwen+fedora
Target Milestone: ---Keywords: Reopened
Target Release: ---   
Hardware: x86_64   
OS: Linux   
Whiteboard: anaconda_trace_hash:ac5616d1fb3e3e46613464757afdb4b0533e3f5610d82870326e06167353087c
Fixed In Version: Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2009-10-21 20:22:07 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:
Attachments:
Description Flags
Attached traceback automatically from anaconda.
none
Attached traceback automatically from anaconda. none

Description Henrik Nordström 2009-10-21 19:19:47 UTC
The following was filed automatically by anaconda:
anaconda 12.37 exception report
Traceback (most recent call first):
  File "/usr/lib/python2.6/site-packages/yum/config.py", line 916, in _getsysver
    if sys.hexversion < 0x02050000:
  File "/usr/lib/python2.6/site-packages/yum/config.py", line 805, in readStartupConfig
    startupconf.releasever = _getsysver(startupconf.installroot, startupconf.distroverpkg)
  File "/usr/lib/python2.6/site-packages/yum/__init__.py", line 249, in _getConfig
    startupconf = config.readStartupConfig(fn, root)
  File "/usr/lib/anaconda/yuminstall.py", line 629, in doConfigSetup
    YumSorter._getConfig(self)
  File "/usr/lib/anaconda/yuminstall.py", line 328, in setup
    self.doConfigSetup(root=self.anaconda.rootPath)
  File "/usr/lib/anaconda/yuminstall.py", line 1060, in doBackendSetup
    self.ayum.setup()
  File "/usr/lib/anaconda/backend.py", line 274, in doBackendSetup
    if anaconda.backend.doBackendSetup(anaconda) == DISPATCH_BACK:
  File "/usr/lib/anaconda/dispatch.py", line 200, in moveStep
    rc = stepFunc(self.anaconda)
  File "/usr/lib/anaconda/dispatch.py", line 123, in gotoNext
    self.moveStep()
  File "/usr/lib/anaconda/gui.py", line 1195, in nextClicked
    self.anaconda.dispatch.gotoNext()
NameError: global name 'sys' is not defined

Comment 1 Henrik Nordström 2009-10-21 19:19:53 UTC
Created attachment 365581 [details]
Attached traceback automatically from anaconda.

Comment 2 Henrik Nordström 2009-10-21 20:03:59 UTC
This is tracked with more detail in bug #527302.

*** This bug has been marked as a duplicate of bug 527302 ***

Comment 3 David Lehman 2009-10-21 20:09:05 UTC
This traceback has nothing to do with the lvm weirdness reported in bug 527302. Let's keep them separate so we can track each individual problem.

Comment 4 seth vidal 2009-10-21 20:22:07 UTC
dupe of 528233

and this is fixed in yum 3.2.25 which is in rawhide and is marked for f12-final.

*** This bug has been marked as a duplicate of bug 528233 ***

Comment 5 Henrik Nordström 2009-10-21 20:43:11 UTC
Eh? It's the traceback from the LVM wierdness case. Or did you mean that I am hitting two separate bugs in the same failing install and that the traceback when anaconda finally gives up the install has nothing to do with the wierdness it does with my LVM volumes prior to that including mounting the completely wrong volume as sysroot?

Comment 6 John Mellor 2009-11-02 23:19:20 UTC
Created attachment 367229 [details]
Attached traceback automatically from anaconda.

Comment 7 Henrik Nordström 2009-11-03 01:29:40 UTC
With the LVM problems fixed there is no traceback for me. And with the LVM problems there is traceback even with fairly recent rawhide, even if slightly different.

For me this was triggered by the LVM issues in Bug #527302 causing /mnt/sysroot to be invalid for the install (a fairly minimal debian etch-amd64 ext3 chroot image instead of expected empty ext4 root). For me it's good it failed with a traceback instead of continuing there as continuing would have created a rather bad mess in that partition.

Johns trace however looks very different and do not share this LVM problem.