This service will be undergoing maintenance at 00:00 UTC, 2016-08-01. It is expected to last about 1 hours

Bug 494124

Summary: Selecting partition on dmraid to be formatted with ext3 and mounted to /boot.
Product: [Fedora] Fedora Reporter: David Krings <ramons>
Component: anacondaAssignee: Anaconda Maintenance Team <anaconda-maint-list>
Status: CLOSED RAWHIDE QA Contact: Fedora Extras Quality Assurance <extras-qa>
Severity: medium Docs Contact:
Priority: low    
Version: rawhideCC: anaconda-maint-list, hdegoede, markku.kolkka, pjones, rmaximo, vanmeeuwen+fedora
Target Milestone: ---   
Target Release: ---   
Hardware: x86_64   
OS: Linux   
Whiteboard: anaconda_trace_hash:91e7e54c7282fbfc36783633128d0f54f7be0a2999ba6b7e9fae444f7926ce6f
Fixed In Version: Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2009-04-08 08:03:44 EDT Type: ---
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Attachments:
Description Flags
Attached traceback automatically from anaconda. none

Description David Krings 2009-04-04 15:12:11 EDT
The following was filed automatically by anaconda:
anaconda 11.5.0.38 exception report
Traceback (most recent call first):
  File "/usr/lib64/python2.6/site-packages/parted/disk.py", line 194, in removePartition
    if self.__disk.remove_partition(partition.getPedPartition()):
  File "/usr/lib/anaconda/storage/devicetree.py", line 697, in _removeDevice
    dev.disk.partedDisk.removePartition(dev.partedPartition)
  File "/usr/lib/anaconda/storage/devicetree.py", line 726, in registerAction
    self._removeDevice(d)
  File "/usr/lib/anaconda/storage/__init__.py", line 612, in createDevice
    self.devicetree.registerAction(ActionCreateDevice(device))
  File "/usr/lib/anaconda/storage/partitioning.py", line 572, in doPartitioning
    storage.createDevice(device)
  File "/usr/lib/anaconda/iw/partition_gui.py", line 1019, in refresh
    doPartitioning(self.storage)
  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
    self.editPartition(device)
  File "/usr/lib/anaconda/iw/partition_gui.py", line 957, in treeActivateCB
    self.editCB()
PartitionException: Attempting to remove an extended partition that still contains logical partitions
Comment 1 David Krings 2009-04-04 15:12:19 EDT
Created attachment 338176 [details]
Attached traceback automatically from anaconda.
Comment 2 Hans de Goede 2009-04-05 05:55:46 EDT
David,

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 11.5.0.40), chances are this is already fixed.

Thanks!
Comment 3 David Krings 2009-04-05 11:33:40 EDT
Hi!
Tried it with the most current rawhide from April 5th which uses anaconda 11.5.0.40. 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....
Comment 4 Hans de Goede 2009-04-06 04:12:01 EDT
*** Bug 494201 has been marked as a duplicate of this bug. ***
Comment 5 Chris Lumens 2009-04-06 10:20:43 EDT
*** Bug 494200 has been marked as a duplicate of this bug. ***
Comment 6 Markku Kolkka 2009-04-06 13:29:21 EDT
(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 11.5.0.40), 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
Comment 7 Hans de Goede 2009-04-08 08:03:44 EDT
Ok,

Yesterday while trying to reproduce this I've fixed a number of bugs related
to the use of an extended partition, including this one:
http://git.fedorahosted.org/git/?p=anaconda.git;a=commitdiff;h=d5449e892ca817f8f0bc19578bacd891f0619ea2

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
were seeing.

Can you please retry with a boot.iso from todays rawhide (Should have anaconda-11.5.0.41) ?

As I believe this is fixed, I'm closing this, if this still happens with anaconda >= anaconda-11.5.0.41, please reopen this bug. Note if you fail to install again, but get a different backtrace now, please open a new bug.