Bug 71012 - Changing partition from ext3 -> SW Raid confuses disk druid
Changing partition from ext3 -> SW Raid confuses disk druid
Status: CLOSED CURRENTRELEASE
Product: Red Hat Enterprise Linux 2.1
Classification: Red Hat
Component: anaconda (Show other bugs)
2.1
ia64 Linux
medium Severity medium
: ---
: ---
Assigned To: Jeremy Katz
Mike McLean
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2002-08-07 15:53 EDT by Glen A. Foster
Modified: 2007-11-30 17:06 EST (History)
1 user (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2003-07-14 18:40:26 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)

  None (edit)
Description Glen A. Foster 2002-08-07 15:53:53 EDT
Caveat: I'm not 100% sure what the problem is here but I've run into something
with disk druid that eventually leads to a "you can't get there from here"
scenario that requires a work-around in order to proceed.

Description of Problem: In an attempt to reproduce bug 70458, I fired up a
Derry-0731 text-mode install.  Using disk druid, I removed the partitions from
/dev/sdb and created (among other things) a 10000MB SW Raid partition.

Then I edited the partitions on /dev/sda, which already had (from a previous
Derry-0731 install) another 10000MB partition of type "ext3".  I was able to
change the partition type from ext3 to SW Raid, and this change was reflected in
the list of partitions for /dev/sda.

When I pressed the "RAID" button, although disk druid listed 2 SW Raid
partitions available, it threw up the error-dialog "You must have 2 SW Raid
partitions" box.  When I removed the newly-changed-to-SW-Raid partition on
/dev/sda and created a new 10000MB SW Raid partition, I was able to make it.

To summarize: either the "EDIT" menu should not allow changing an existing
partition to type SW-Raid -or- disk druid is not counting/adjusting the number
of SW-Raid partitions correctly.

Version-Release number of selected component (if applicable):
Derry-0731

How Reproducible: Fairly easy.
Comment 1 Jeremy Katz 2002-08-20 17:17:11 EDT
I can't reproduce this here -- are you sure that you didn't accidentally
unselect one of the partitions?
Comment 2 Glen A. Foster 2002-08-23 14:28:34 EDT
I just reproduced the issue with Derry-0821.  Here's how I did it:
[Harfware == Wilson Peak with 2 drives]

Step #1: install a distribution.(min. install is OK) formatted as follows:
    - clear out all partitions on /dev/hda AND /dev/hdb
    - create /boot/efi, swap, etc.
    == CREATE / as EXACTLY 15000M, ext3 file system
    - continue with install (should work fine) -- in fact I was wondering if
          a reboot following the first package installation would shorten the
          time required to reproduce this, since the partitions are formatted.

Step #2: re-install (any type)
    - keep /boot/efi and swap
    - create 15000M "Software RAID" partition on /dev/hdb
    - select ext3 15000M partition on /dev/hda, press EDIT
        == select "Filesystem Options"
            --> tell it to format the partition as "Software RAID"
            --> press OK
    - press "RAID" button

... there's your error message.  Says you must have 2 RAID partitions (and disk
druid tells me I do) so something is amiss -- either the counting of SW RAID
partitions, or the fact that I can re-format it as SW RAID.  Dunno.

If first install is minimal, whole procedure can take 20-30 minutes.

QED. :-)
Comment 3 Tim Burke 2002-09-12 15:02:29 EDT
Today's status meeting update: Jeremy says that there's an easy workaround to
just delete the partition first.
Comment 4 Glen A. Foster 2003-02-26 15:50:58 EST
I think I need clarification here.  Is the workaround to simply delete the 
partition something that *I* as the user should do, or is it something that
anaconda needs to add to the code when the partition type is changed?

As coded, anaconda puts the user into a position where a seemingly valid 
operation (I assume it's valid since the U/I lets me change this) cannot
work.  User interfaces with stringent usability design (ideally) should
not allow a user to get into a function that cannot happen.

So will this be repaired, or closed as NOTABUG?  /me hopes the former.
Comment 5 Matt Wilson 2003-04-03 23:00:09 EST
normalizing Version in Red Hat Linux Beta product
Comment 6 Larry Troan 2003-05-13 10:48:01 EDT
ISSUE TRACKER 21402 opened as sev 2 
Comment 7 Larry Troan 2003-06-24 12:00:45 EDT
I talked with Jeremy. This is fixed in Taroon and will not be fixed in AS2.1.
The workaround for 2.1 is to have the user delete the partition first.  

Suggest you verify fixed in Taroon and we close the Bug.

(also fixing release to RHEL since this appeared on Derry) 
Comment 8 Glen A. Foster 2003-06-25 09:31:32 EDT
It sounds like the decision is made.  What particular information is being
waited for -- HP's approval for this decision?  If so, consider it given.  If
not, let me know what other information is needed, and reset this defect to
NEEDINFO .
Comment 9 Larry Troan 2003-06-25 14:15:08 EDT
Need confirmation that fixed in Taroon before closing Bug.
Comment 10 Michael Fulbright 2003-07-14 12:40:38 EDT
What is the status of this bug?
Comment 11 Glen A. Foster 2003-07-14 18:38:40 EDT
I have confirmed that the issue IS NOT FIXED with AS2.1 update 2.
I have further confirmed that the issue IS FIXED in Taroon alpha 4, at least as
far as determining that disk druid no longer complains and needing more RAID
devices.
Comment 12 Jeremy Katz 2003-07-14 18:40:26 EDT
Okay, fixed in Taroon, not going to be backported

Note You need to log in before you can comment on or make changes to this bug.