Bug 532214

Summary: F12 Anaconda faults with multiple disks in root vg
Product: [Fedora] Fedora Reporter: John Mellor <john.mellor>
Component: yumAssignee: Seth Vidal <skvidal>
Status: CLOSED DUPLICATE QA Contact: Fedora Extras Quality Assurance <extras-qa>
Severity: high Docs Contact:
Priority: low    
Version: rawhideCC: ffesti, james.antill, maxamillion, pmatilai, tim.lauridsen, vanmeeuwen+fedora
Target Milestone: ---   
Target Release: ---   
Hardware: i686   
OS: Linux   
Whiteboard:
Fixed In Version: Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2009-11-05 20:07:43 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
teaceback from filesystem creation none

Description John Mellor 2009-10-31 14:09:17 UTC 
Description of problem:
I use an old Dell T800r as my beta testbed.  It has 512M RAM, 1x800MHz P3, 2 drives installed: a 9G PATA and a 4G PATA.  If I do a fresh install using F12-beta and the default of both drives selected, anaconda blows chunks.  It does not matter if I use the default LVM or force use of EXT3 or 4 for the volumes.

Deselecting the second drive allows anaconda to succeed, and install proceeds.

Version-Release number of selected component (if applicable):


How reproducible:
every time

Steps to Reproduce:
1.
2.
3.
  
Actual results:
unexpected traceback

Expected results:
normal installation

Additional info:
Comment 1 Chris Lumens 2009-11-02 14:21:09 UTC 
Please attach the complete traceback to this bug report, as there's not really enough information here for me to tell what's going wrong.
Comment 2 John Mellor 2009-11-03 00:29:12 UTC 
Using the automatic bugzilla filing, this marks itself as a duplicate of bugzilla 530174 related to a fault in lvm.  However the traceback is different, so I doubt that.  This bug also present using ext4 instead of lvm, so it would seem unlikely.  Also, 530174 is marked a a duplicate of 528233, which has completely different symptoms and a solution involving a new upstream version of yum, which is clearly not the problem here.

As an aside, this would seem to indicate that 530174 has been marked as a duplicate in error, and there is an uncorrected bug.  530174 should be re-opened.
Comment 3 John Mellor 2009-11-03 00:30:25 UTC 
Created attachment 367233 [details]
teaceback from filesystem creation
Comment 4 Chris Lumens 2009-11-05 20:04:04 UTC 
Traceback from attached file:

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 5 seth vidal 2009-11-05 20:07:43 UTC 

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