Created attachment 318073 [details] screen shot of the assertion GUI message Description of problem: Assertion failure Version-Release number of selected component (if applicable): anaconda-11.1.2.132-1 How reproducible: Always Steps to Reproduce: 0. I have encrypted partitions (sda2 and sdb1) on the disk prior to install 1. Boot the installer (vnc mode) 2. When asked to enter the pass phrase to unlock previously encrypted partitions select Cancel and proceed 3. At partitioning screen leave defaults and proceed - an error message is shown explaining the problem. After clicking OK you're placed in the partitioning screen again. 4. Instead of the default (remove linux partitions ...) select remove all partitions on the system ... and click Next 5. A similar error message as in 3) is shown. Click OK 6. Leave the previous selection as is and click Next again when at partitioning screen Actual results: Assertion failure and install hangs Expected results: Error dialog as shown previously Additional info: message on tty1 Backtrace has 20 calls on stack: 20: /usr/lib/libparted-1.8.so.0(ped_assert-0x2a646d0) [0x2000000001b7dd00] 19: /usr/lib/libparted-1.8.so.0(ped_disk_remove_partition-0x2a57150) [0x2000000001b8b290] 18: /usr/lib/libparted-1.8.so.0(ped_disk_delete_partition-0x2a56da0) [0x2000000001b8b650] 17: /usr/lib/python2.4/site-packages/partedmodule.so [0x2000000002ab0dc0] 16: /usr/lib/libpython2.4.so.1.0(PyCFunction_Call+0xbed80) [0x200000000010b2a0] 15: /usr/lib/libpython2.4.so.1.0(PyEval_EvalFrame-0x4444400) [0x200000000019e000] 14: /usr/lib/libpython2.4.so.1.0(PyEval_EvalFrame-0x4447fb0) [0x200000000019a450] 13: /usr/lib/libpython2.4.so.1.0(PyEval_EvalCodeEx-0x44421c0) [0x20000000001a0250] 12: /usr/lib/libpython2.4.so.1.0(PyEval_EvalFrame-0x4448120) [0x200000000019a2e0] 11: /usr/lib/libpython2.4.so.1.0(PyEval_EvalFrame-0x4447fb0) [0x200000000019a450] 10: /usr/lib/libpython2.4.so.1.0(PyEval_EvalCodeEx-0x44421c0) [0x20000000001a0250] 9: /usr/lib/libpython2.4.so.1.0(PyEval_EvalFrame-0x4448120) [0x200000000019a2e0] 8: /usr/lib/libpython2.4.so.1.0(PyEval_EvalFrame-0x4447fb0) [0x200000000019a450] 7: /usr/lib/libpython2.4.so.1.0(PyEval_EvalFrame-0x4447fb0) [0x200000000019a450] 6: /usr/lib/libpython2.4.so.1.0(PyEval_EvalCodeEx-0x44421c0) [0x20000000001a0250] 5: /usr/lib/libpython2.4.so.1.0 [0x20000000000dd990] 4: /usr/lib/libpython2.4.so.1.0(PyObject_Call-0x453f3b0) [0x20000000000a3070] 3: /usr/lib/libpython2.4.so.1.0 [0x20000000000b2d90] 2: /usr/lib/libpython2.4.so.1.0(PyObject_Call-0x453f3b0) [0x20000000000a3070] 1: /usr/lib/libpython2.4.so.1.0(PyEval_CallObjectWithKeywords-0x4452140) [0x20000000001902f0] Bug Assertion (part->part_list == NULL) at disk.c:1881 in function ped_disk_remove_partition() failed. 96
Created attachment 318075 [details] video (1MB) of the install steps
looks like same thing happens when I enter the pass phrase for the encrypted partitions. I see two bugs here: 1) the assertion failure which probably needs to be handled gracefully 2) since all encrypted partitions have been unlocked with a global pass phrase shouldn't anaconda just create the default partitioning scheme (LVM) when instructed to do so instead of telling me that it can't allocate partitions? Is it trying to preserve the already existing encrypted partitions? If yes, I haven't seen this documented anywhere.
First, the obvious question: Has the same scenario been attempted without pre-existing encrypted block devices? To address item #2 in comment #2: Being encrypted should have no bearing on whether or not a partition is considered to be a "linux" partition.
(In reply to comment #3) > First, the obvious question: Has the same scenario been attempted without > pre-existing encrypted block devices? > If there are no encrypted devices then: 1. Boot the installer (vnc mode) 2. At partitioning screen leave defaults and proceed 3. Installer goes to next step and install completes > To address item #2 in comment #2: Being encrypted should have no bearing on > whether or not a partition is considered to be a "linux" partition. Is the ability to remove "All linux partitions" affected by the fact that encrypted partitions were not unlocked? I suppose not.
Well, I thought maybe you were onto something with the encrypted partitions not being accessible but it seems that case is covered also. I just tried to reproduce here and was unsuccessful. I created encrypted partitions that filled the vast majority of both disks. I canceled out of the passphrase dialogs, then tried the default autopartitioning -- no error messages. How about booting with "debug" on the command line and poking around some when you get the first error. Maybe print all of the requests (anaconda.id.partitions.requests).
Do we have a reproducer in a environment that is not installation. Where parted cannot remove an encrypted partition?
Created attachment 319250 [details] another error message Dave, I've tried with the 0930.0 tree which has anaconda-11.1.2.132-1 doing: 1) Install with default partitioning, select encrypted which creates one volume group with encrypted PVs. system boots fine 2) do a second install which: 3) when asked for a pass phrase click cancel 4) leave the default partitioning scheme (remove all linux partitions) and do NOT select encrypt system checkbox. I can proceed with the install however while the partitions are being formatted i see another error (see screen shot). Please advise if you need another bug filed for it or we can track it in this one.
Created attachment 319251 [details] anaconda.log for comment #8
Are you able to reproduce this reliably, or is it possible that these errors are somehow spurious? I followed the instructions in comment #0 and in comment #8 and in neither case was I able to produce any error at all. If it does happen that you are able to reproduce the failure from comment #8 reliably, please do open a new bug for it.
Comment #8 filed as bug #465460
So is this actually only occurring on ia64 like the problem from comment #8 (aka bug #465460)? Because if it is, that might explain why I cannot reproduce it on my i386 test hardware. It would have really helped if you had mentioned this being ia64 at some point.
I haven't tested on other platforms so I don't really know. It looks liked like arch speciffic but with the latest build I couldn't reproduce as well.
Alexander, is this still not reproducing?
Couldn't reproduce with latest nightly build. I think we're safe to close this issue for now.
Closing as Alex could not reproduce with latest nightly.