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.
Created attachment 335583 [details] anaconda.log
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.
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.
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
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.