Bugzilla will be upgraded to version 5.0 on a still to be determined date in the near future. The original upgrade date has been delayed.
Bug 100802 - Anaconda barfs when it's about to format ths disks
Anaconda barfs when it's about to format ths disks
Product: Red Hat Linux
Classification: Retired
Component: anaconda (Show other bugs)
i686 Linux
medium Severity medium
: ---
: ---
Assigned To: Jeremy Katz
Mike McLean
Depends On:
  Show dependency treegraph
Reported: 2003-07-25 13:12 EDT by David Tonhofer
Modified: 2007-04-18 12:56 EDT (History)
0 users

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Last Closed: 2004-10-04 23:20:21 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Attachments (Terms of Use)
Anaconda dump file (130.96 KB, text/plain)
2003-07-25 13:13 EDT, David Tonhofer
no flags Details

  None (edit)
Description David Tonhofer 2003-07-25 13:12:44 EDT
From Bugzilla Helper:
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.0.2)
Gecko/20030208 Netscape/7.02

Description of problem:
The dump is attached. This occurs in the graphical RH setup just
after package selection, when we are about to format the disks

Nonclassical things I do/have/did:

- Two IDE drives /dev/hde and /dev/hdg in software RAID-1 configuration
- Boot device is going to be /dev/md1 NOT /dev/md0 (is this a sin?),
  with LILO
- Tried to modify the root password after having set it (with 'back'
  and that didn't work, incidentally)
- Drink lots of green tea and eat bananas while waiting for
  installer to finish

How reproducible:
Didn't try

Steps to Reproduce:
1. Set up RH 9
2. Get to after the point where package info was entered
3. Bampf!

Actual Results:  Bad things

Expected Results:  Good things
Comment 1 David Tonhofer 2003-07-25 13:13:43 EDT
Created attachment 93154 [details]
Anaconda dump file
Comment 2 David Tonhofer 2003-07-25 13:32:41 EDT
Uh oh! Something must have gone wrong with the assignation of the md

I restarted the setup process and there are md devices

md3 md7 md8 md5 md4 md1 md6 md1 md0 md2

I was sure I had them set to 

md1 md2 md3 md5 md6 md7 md8 md9 md10 md11 md12 md13

The idea was to reflect the structure of the underlying hde/hdg partitions.
I will be reasonable now and count from 0 and not do jumps in the md series.
Comment 3 Jeremy Katz 2003-07-25 23:09:27 EDT
Did you have preexising RAID devices on the system before you reinstalled?
Comment 4 David Tonhofer 2003-07-29 04:59:32 EDT
The system had a RH 8.0 installation but the two disks were not in a RAID
setup. I decided to scratch everything, but keep the partitioning of the
disks (it was exactly alike on both disks). So I just marked them as
'software raid' then paired them into mirrors in disk druid:

md1  = hde1  + hdg1  (primary, will hold /boot) 
md2  = hde2  + hdg2  (primary, will hold /)
md3  = hde3  + hdg3  (primary, will hold <swap>)
md5  = hde5  + hdg5  (secondary, will hold /tmp)
md6  = hde6  + hdg6  (secondary, will hold /home)
md7  = hde7  + hdg7   ...etc...
md8  = hde8  + hdg8
md9  = hde8  + hdg9
md10 = hde10 + hdg10
md11 = hde11 + hdg11
md12 = hde12 + hdg12
md13 = hde13 + hdg13
Comment 6 Jeremy Katz 2004-10-04 23:20:21 EDT
This looks like it should be working better in our current releases.

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