Bug 493058

Summary: Custom partitioning creation/edit causes traceback
Product: [Fedora] Fedora Reporter: James Laska <jlaska>
Component: anacondaAssignee: David Lehman <dlehman>
Status: CLOSED NEXTRELEASE QA Contact: Fedora Extras Quality Assurance <extras-qa>
Severity: high Docs Contact:
Priority: low    
Version: 11CC: awilliam, bochecha, ddumas, fedora, jgranado, jturner, me, notting, piotrdrag, r.henninger, rmaximo, tcallawa, vanmeeuwen+fedora, zootboysean+rhbz
Target Milestone: ---   
Target Release: ---   
Hardware: All   
OS: Linux   
Whiteboard:
Fixed In Version: Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2009-10-30 11:26:07 EDT Type: ---
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Bug Depends On:    
Bug Blocks: 531381    
Attachments:
Description Flags
anaconda-logs.tgz (anaconda.log, anacdump.txt, storage.log, program.log)
none
Attached traceback automatically from anaconda. none

Description James Laska 2009-03-31 10:01:19 EDT
Created attachment 337307 [details]
anaconda-logs.tgz (anaconda.log, anacdump.txt, storage.log, program.log)

Description of problem:

While creating and removing partitions at the partition detail screen, I get a traceback.

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

How reproducible:


Steps to Reproduce:
1. Initiate installation, proceed to partition detail screen
2. Remove *all* existing partitions
3. Create /boot ext3 200M
4. Create SOFTWARE RAID 7G (force primary)
5. Create SOFTWARE RAID 7G (force primary)
6. Create Swap (fill to recommended size)
  
Actual results:

I iterated through steps 4-6 several times ... and eventually hit

Error in sys.excepthook:
Traceback (most recent call last):
  File "/usr/bin/anaconda", line 1026, in <lambda>
    sys.excepthook = lambda type, value, tb, anaconda=anaconda: handleException(anaconda, (type, value, tb))
  File "/usr/lib/anaconda/exception.py", line 644, in handleException
    runSaveDialog(anaconda, exn)
  File "/usr/lib/anaconda/exception.py", line 489, in runSaveDialog
    saveWin = anaconda.intf.saveExceptionWindow(anaconda, exn.tbFile)
  File "/usr/lib/anaconda/gui.py", line 1209, in saveExceptionWindow
    win = SaveExceptionWindow (anaconda, longTextFile)
  File "/usr/lib/anaconda/gui.py", line 744, in __init__
    dests = anaconda.id.storage.exceptionDisks()
  File "/usr/lib/anaconda/storage/__init__.py", line 441, in exceptionDisks
    for device in self.devices:
  File "/usr/lib/anaconda/storage/__init__.py", line 279, in devices
    devices = self.devicetree.devices.values()
  File "/usr/lib/anaconda/storage/devicetree.py", line 1574, in devices
    raise DeviceTreeError("duplicate paths in device tree")
storage.errors.DeviceTreeError: duplicate paths in device tree

Original exception was:
Traceback (most recent call last):
  File "/usr/lib/anaconda/iw/partition_gui.py", line 976, in newCB
    self.editPartition(device, isNew=1)
  File "/usr/lib/anaconda/iw/partition_gui.py", line 1134, in editPartition
    if self.refresh():
  File "/usr/lib/anaconda/iw/partition_gui.py", line 1019, in refresh
    doPartitioning(self.storage)
  File "/usr/lib/anaconda/storage/partitioning.py", line 532, in doPartitioning
    disks = storage.disks
  File "/usr/lib/anaconda/storage/__init__.py", line 294, in disks
    devices = self.devicetree.devices
  File "/usr/lib/anaconda/storage/devicetree.py", line 1574, in devices
    raise DeviceTreeError("duplicate paths in device tree")
storage.errors.DeviceTreeError: duplicate paths in device tree


Expected results:

Should not traceback

Additional info:

 * SaveToBugzilla was impacted as well ... appears I couldn't direct file this bug using anaconda.
Comment 1 Chris Lumens 2009-03-31 11:55:37 EDT
I've taken care of the exception in the error reporting code, which just leaves the real bug to solve.
Comment 2 Chris Lumens 2009-04-06 16:33:25 EDT
*** Bug 494131 has been marked as a duplicate of this bug. ***
Comment 3 Joel Andres Granados 2009-04-24 09:45:20 EDT
Tested a few fixes and I found out that this bug is caused by the order of the new_partitions (partitioning.py:617) list.  This specific code path makes the forced primary partitions to be at the end of the list.  And when we assume that the last partition must be an extended one we get an error because we can't have forced primary partitions in extended partitions.
Comment 4 Chris Lumens 2009-05-05 15:55:19 EDT
*** Bug 499236 has been marked as a duplicate of this bug. ***
Comment 5 Bill Nottingham 2009-05-28 22:32:08 EDT
Does this reproduce with the RC images?
Comment 6 Bug Zapper 2009-06-09 08:50:58 EDT
This bug appears to have been reported against 'rawhide' during the Fedora 11 development cycle.
Changing version to '11'.

More information and reason for this action is here:
http://fedoraproject.org/wiki/BugZappers/HouseKeeping
Comment 7 Piotr Drąg 2009-06-09 15:43:37 EDT
Still reproducible on final Fedora 11 release images.
Comment 8 Piotr Drąg 2009-06-09 15:48:58 EDT
Created attachment 347081 [details]
Attached traceback automatically from anaconda.
Comment 9 Edwin ten Brink 2009-06-17 17:03:10 EDT
Confirming on Fedora 11 i386 DVD release image.

Changing severity to high since the installer crashes which makes installation impossible if the partition layout has to be modified manually.

Note the slowly increasing number of automatically generated reports by anaconda in bug 499236 which has been marked as a duplicate of this bug.

Save bugreport to local disk did not work for me by the way, possibly because of this bug. Save to bugzilla did.
Comment 10 Joel Andres Granados 2009-08-06 04:47:57 EDT
is this still present in rawhide.  I can't reproduce with my previous test case.  Comment #1 reproducer does not seem to show the bug either.
Comment 11 Joel Andres Granados 2009-08-19 06:01:16 EDT
placing on modified as I cant reproduce anymore.
Comment 12 Zootboy 2009-09-02 17:09:38 EDT
I have experienced what may be this bug. I have tested a few different setups and I think that anaconda will crash when there is extended partitions in the filesystem.

I got this bugreport from the F11 install, but I have confirmed that the bug exists in the F12 alpha release as well:

anaconda 11.5.0.59 exception report
Traceback (most recent call first):
  File "/usr/lib/python2.6/site-packages/yum/config.py", line 867, in _getsysver
    idx = ts.dbMatch('provides', distroverpkg)
  File "/usr/lib/python2.6/site-packages/yum/config.py", line 794, in readMainConfig
    yumvars['releasever'] = _getsysver(startupconf.installroot, startupconf.distroverpkg)
  File "/usr/lib/python2.6/site-packages/yum/__init__.py", line 239, in _getConfig
    self._conf = config.readMainConfig(startupconf)
  File "/usr/lib/anaconda/yuminstall.py", line 588, in doConfigSetup
    YumSorter._getConfig(self)
  File "/usr/lib/anaconda/yuminstall.py", line 300, in __init__
    self.doConfigSetup(root=anaconda.rootPath)
  File "/usr/lib/anaconda/yuminstall.py", line 1018, in doBackendSetup
    self.ayum = AnacondaYum(anaconda)
  File "/usr/lib/anaconda/backend.py", line 271, in doBackendSetup
    if anaconda.backend.doBackendSetup(anaconda) == DISPATCH_BACK:
  File "/usr/lib/anaconda/dispatch.py", line 205, in moveStep
    rc = stepFunc(self.anaconda)
  File "/usr/lib/anaconda/dispatch.py", line 128, in gotoNext
    self.moveStep()
  File "/usr/lib/anaconda/gui.py", line 1339, in nextClicked
    self.anaconda.dispatch.gotoNext()
TypeError: rpmdb open failed
...
Comment 13 Joel Andres Granados 2009-09-08 09:33:52 EDT
(In reply to comment #12)
> I have experienced what may be this bug. I have tested a few different setups
> and I think that anaconda will crash when there is extended partitions in the
> filesystem.
> 
> I got this bugreport from the F11 install, but I have confirmed that the bug
> exists in the F12 alpha release as well:
> 
> anaconda 11.5.0.59 exception report
^^^^^^^ this is f11 anaconda.  Can you pls test with rawhide?
Comment 14 Zootboy 2009-09-10 11:14:11 EDT
I did test it with the alpha, I said so in my comment above. Would you like the bug report from it?
Comment 15 Adam Williamson 2009-10-21 11:38:44 EDT
zootboy: can you please test with a current F12 (like the Beta, released yesterday) and see if you can still hit this problem? If so, provide the report from that release. Thanks very much!

-- 
Fedora Bugzappers volunteer triage team
https://fedoraproject.org/wiki/BugZappers
Comment 16 David Lehman 2009-10-21 11:54:31 EDT
What makes us think the traceback in comment 12 is at all related the original reported problem? The tracebacks look completely different to me.
Comment 17 Adam Williamson 2009-10-21 18:55:57 EDT
dave: not a lot, but I thought we'd best get an updated trace (if he's still hitting a problem in beta) so we can tell for sure what he's hitting in f12.

-- 
Fedora Bugzappers volunteer triage team
https://fedoraproject.org/wiki/BugZappers
Comment 18 Adam Williamson 2009-10-30 11:26:07 EDT
Via today's blocker bug review meeting: closing due to lack of feedback from zootboy, from all other feedback this seems fixed for Fedora 12. zootboy, if you are still experiencing something similar and are around to provide information, please file a new bug with your traceback. Thanks.

-- 
Fedora Bugzappers volunteer triage team
https://fedoraproject.org/wiki/BugZappers