Bug 490736 - ped_assert failure during install
Summary: ped_assert failure during install
Keywords:
Status: CLOSED RAWHIDE
Alias: None
Product: Fedora
Classification: Fedora
Component: pyparted
Version: rawhide
Hardware: All
OS: Linux
low
medium
Target Milestone: ---
Assignee: David Cantrell
QA Contact: Fedora Extras Quality Assurance
URL:
Whiteboard:
Depends On:
Blocks: F11Beta, F11BetaBlocker
TreeView+ depends on / blocked
 
Reported: 2009-03-17 19:00 UTC by Orion Poplawski
Modified: 2009-03-19 17:18 UTC (History)
2 users (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
Environment:
Last Closed: 2009-03-19 17:18:22 UTC
Type: ---
Embargoed:


Attachments (Terms of Use)
anaconda storage.log (15.11 KB, text/plain)
2009-03-17 19:00 UTC, Orion Poplawski
no flags Details
anaconda.log (11.07 KB, text/plain)
2009-03-17 19:01 UTC, Orion Poplawski
no flags Details

Description Orion Poplawski 2009-03-17 19:00:25 UTC
Created attachment 335582 [details]
anaconda storage.log

Description of problem:

Trying to do kickstart install of today's (20090317) rawhide.  A xen install is going fine, but an install on a laptop crashes in ped_assert under ped_remove_partition.

Comment 1 Orion Poplawski 2009-03-17 19:01:47 UTC
Created attachment 335583 [details]
anaconda.log

Comment 2 Joel Andres Granados 2009-03-18 08:10:24 UTC
There are 3 layers before actually getting to parted during install: 1.anaconda, 2: pyparted, 3:libparted.  The third one is actually part of parted.  Can you reproduce in a running system?

Additionally.  anaconda is going through a massive rewrite ATM, so this issues will be common place for a few weeks.  I'm going to leave this open an revisit it once all the dust has settled in anaconda rewrite world.

Comment 3 Chris Lumens 2009-03-19 14:17:53 UTC
It'd additionally be helpful to see the assertion and backtrace itself, which is probably found on tty1.  That'll let us know exactly what's going on here.  In the simplest case, it could just be something that libparted asserts on that we need to catch in pyparted.

Comment 4 Orion Poplawski 2009-03-19 15:04:21 UTC
Hope this is enough:

/lib64/libparted-1.8.so.8(ped_assert+0x8a)
/lib64/libparted-1.8.so.8
/lib64/libparted-1.8.so.8
/lib64/libparted-1.8.so.8(ped_disk_remove_partition+0xeb)
/usr/lib64/python2.6/site-packages/_pedmodule.so(py_ped_disk_remove_partition+0xb8)
/usr/lib64/libpython2.6.so.1.0(PyEval_EvalFrameEx
/usr/lib64/libpython2.6.so.1.0(PyEval_EvalCodeEx
/usr/lib64/libpython2.6.so.1.0(PyEval_EvalFrameEx
/usr/lib64/libpython2.6.so.1.0(PyEval_EvalCodeEx
/usr/lib64/libpython2.6.so.1.0(PyEval_EvalFrameEx
/usr/lib64/libpython2.6.so.1.0(PyEval_EvalFrameEx
/usr/lib64/libpython2.6.so.1.0(PyEval_EvalFrameEx
/usr/lib64/libpython2.6.so.1.0(PyEval_EvalFrameEx
/usr/lib64/libpython2.6.so.1.0(PyEval_EvalFrameEx
/usr/lib64/libpython2.6.so.1.0(PyEval_EvalCodeEx
/usr/lib64/libpython2.6.so.1.0(PyEval_EvalFrameEx
/usr/lib64/libpython2.6.so.1.0
/usr/lib64/libpython2.6.so.1.0(PyObject_Call
/usr/lib64/libpython2.6.so.1.0

Comment 5 Chris Lumens 2009-03-19 17:18:22 UTC
Looks like anaconda is attempting to remove an extended partition without removing the logical partitions contained in it first.  libparted asserts on this condition, which means pyparted needs to check for it before making the call.  I've updated pyparted.  We will need to fix anaconda to do the deletes in the right order, but I believe we have a bug for this already.  Thanks for gathering the extra information.


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