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):
How Reproducible: Fairly easy.
I can't reproduce this here -- are you sure that you didn't accidentally
unselect one of the partitions?
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.
Today's status meeting update: Jeremy says that there's an easy workaround to
just delete the partition first.
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.
normalizing Version in Red Hat Linux Beta product
ISSUE TRACKER 21402 opened as sev 2
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)
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
Need confirmation that fixed in Taroon before closing Bug.
What is the status of this bug?
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
Okay, fixed in Taroon, not going to be backported