Red Hat Bugzilla – Bug 494124
Selecting partition on dmraid to be formatted with ext3 and mounted to /boot.
Last modified: 2009-04-08 08:03:44 EDT
The following was filed automatically by anaconda:
anaconda 188.8.131.52 exception report
Traceback (most recent call first):
File "/usr/lib64/python2.6/site-packages/parted/disk.py", line 194, in removePartition
File "/usr/lib/anaconda/storage/devicetree.py", line 697, in _removeDevice
File "/usr/lib/anaconda/storage/devicetree.py", line 726, in registerAction
File "/usr/lib/anaconda/storage/__init__.py", line 612, in createDevice
File "/usr/lib/anaconda/storage/partitioning.py", line 572, in doPartitioning
File "/usr/lib/anaconda/iw/partition_gui.py", line 1019, in refresh
File "/usr/lib/anaconda/iw/partition_gui.py", line 1127, in editPartition
if self.refresh(justRedraw=not actions):
File "/usr/lib/anaconda/iw/partition_gui.py", line 1082, in editCB
File "/usr/lib/anaconda/iw/partition_gui.py", line 957, in treeActivateCB
PartitionException: Attempting to remove an extended partition that still contains logical partitions
Created attachment 338176 [details]
Attached traceback automatically from anaconda.
I'm going to need some more details to reproduce this, what exactly where you doing when you hit this, how did your system (disks, partitions) look like before
you hit this, etc.
Also note that quite a few fixes have gone in anaconda since the beta, can you
please try using the boot.iso from todays (04-04) rawhide (anaconda version should be 184.108.40.206), chances are this is already fixed.
Tried it with the most current rawhide from April 5th which uses anaconda 220.127.116.11. No dice with that one either.
I crafted a new bug report under 494201 (I'd like to have it attached to this one, but there appears to be no way to do that from the installer, probably better that way). Three things I tried and they each appear to create the exact same crash:
- reuse an existing partition
- delete a partition with the intention to create a new one
- replace the existing linux system (currently OpenSuSE, the only distro that has no problem installing on this setup, sorry)
The bug report is from the partition delete try. I did not file an extra bug report for the reuse of existing system attempt.
I have two 'drives' in the box: the FakeRAID on the nVidia mapper device and a single drive on the SiI controller. BIOS is set to boot from the single drive, because (SuSE's ?) GRUB is too stupid to write the MBR on the mapper device. The partitions are as follows:
A) Mapper device on nVidia controller - FakeRAID:
partition 1: primary, linux boot, ext3, 300 MB
partition 2: primary, Windows, NTFS, 60 GB
partition 3: extended
partition 5: logical, Windows, NTFS, 85 GB
partition 6: logical, Windows, NTFS, 85 GB
partition 7: logical, Linux, swap, 2 GB
partition 8: logical, Linux, ext3, 70 GB
There are a few GB of free space as partitioners in general seem to be unable to use all of the available drive space. Not a Linux-only issue, but one that is utterly annoying.
This partitioning was originally done by an OpenSuSE install (no clue exactly which one) and I haven't changed the partitions since then except for reformatting to test/update/try things out, etc. At the moment the currently OpenSuSE release is installed.
B) Single drive on SiI controller, non-RAID, boot disk (GRUB issue, see above):
1 primary partition as NTFS
What did is boot from CD/DVD, chose first entry in boot menu, clicked Next, selected language (English), keyboard layout (German), left the default computer name, default time zone (EST, system clock is not UTC), then performed the steps in the partitioner section.
Somewhere in there I also entered a root password and OKed that it is a beta release.
Just to point it out: I think of RedHat/Fedora as the distro I'd like to use. OpenSuSE and Ubuntu are alternatives I consider. Problem with Ubuntu is that it, too, does not install on this setup (although Debian does!), OpenSuSE does install, but I don't really like it. I could install Fedora on the single drive, but that defeats the purpose of having the RAID.
Since I need the Windope install for video NLE (Linux offerings don't cut it yet, pun intended) I won't just wipe the entire array and start over. While that may work in the end I don't think it is practical.
What I don't understand is why various incarnations of DOS and Windows as well as OpenSuSE have no problems with this. I don't say it is trivial by any means, but doesn't the BIOS fake it so that any standard request for drive information returns a single drive? Would it help to write to nVidia and complain that they don't have open-source GPL'ed Linux drivers? Anything else I can provide as information?
Sorry for being so clueless....
*** Bug 494201 has been marked as a duplicate of this bug. ***
*** Bug 494200 has been marked as a duplicate of this bug. ***
(In reply to comment #2)
> Also note that quite a few fixes have gone in anaconda since the beta, can you
> please try using the boot.iso from todays (04-04) rawhide (anaconda version
> should be 18.104.22.168), chances are this is already fixed.
I got a similar exception while using 04-04 rawhide together with update image from https://bugzilla.redhat.com/show_bug.cgi?id=491348#c27
The traceback is in https://bugzilla.redhat.com/attachment.cgi?id=338236
Yesterday while trying to reproduce this I've fixed a number of bugs related
to the use of an extended partition, including this one:
When I tried to reproduce today (now I've managed to get past the problems I fixed yesterday, so I can first do an install with an extended partition present)
and I can not reproduce. Looking at the backtrace you posted I can most likely
not reproduce because of above fix, which I believe fixes the backtrace you
Can you please retry with a boot.iso from todays rawhide (Should have anaconda-22.214.171.124) ?
As I believe this is fixed, I'm closing this, if this still happens with anaconda >= anaconda-126.96.36.199, please reopen this bug. Note if you fail to install again, but get a different backtrace now, please open a new bug.