Bug 490736 - ped_assert failure during install
ped_assert failure during install
Status: CLOSED RAWHIDE
Product: Fedora
Classification: Fedora
Component: pyparted (Show other bugs)
rawhide
All Linux
low Severity medium
: ---
: ---
Assigned To: David Cantrell
Fedora Extras Quality Assurance
:
Depends On:
Blocks: F11Beta/F11BetaBlocker
  Show dependency treegraph
 
Reported: 2009-03-17 15:00 EDT by Orion Poplawski
Modified: 2009-03-19 13:18 EDT (History)
2 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2009-03-19 13:18:22 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


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

  None (edit)
Description Orion Poplawski 2009-03-17 15:00:25 EDT
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 15:01:47 EDT
Created attachment 335583 [details]
anaconda.log
Comment 2 Joel Andres Granados 2009-03-18 04:10:24 EDT
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 10:17:53 EDT
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 11:04:21 EDT
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 13:18:22 EDT
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.