Bug 490736
| Summary: | ped_assert failure during install | ||||||||
|---|---|---|---|---|---|---|---|---|---|
| Product: | [Fedora] Fedora | Reporter: | Orion Poplawski <orion> | ||||||
| Component: | pyparted | Assignee: | Dave Cantrell <dcantrell> | ||||||
| Status: | CLOSED RAWHIDE | QA Contact: | Fedora Extras Quality Assurance <extras-qa> | ||||||
| Severity: | medium | Docs Contact: | |||||||
| Priority: | low | ||||||||
| Version: | rawhide | CC: | dcantrell, jgranado | ||||||
| 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-03-19 17:18:22 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: | |||||||||
| Bug Depends On: | |||||||||
| Bug Blocks: | 476774 | ||||||||
| Attachments: |
|
||||||||
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. |
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.