Bug 100802 - Anaconda barfs when it's about to format ths disks
Summary: Anaconda barfs when it's about to format ths disks
Alias: None
Product: Red Hat Linux
Classification: Retired
Component: anaconda (Show other bugs)
(Show other bugs)
Version: 9
Hardware: i686 Linux
Target Milestone: ---
Assignee: Jeremy Katz
QA Contact: Mike McLean
Depends On:
TreeView+ depends on / blocked
Reported: 2003-07-25 17:12 UTC by David Tonhofer
Modified: 2007-04-18 16:56 UTC (History)
0 users

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Last Closed: 2004-10-05 03:20:21 UTC
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 17:13 UTC, David Tonhofer
no flags Details

Description David Tonhofer 2003-07-25 17:12:44 UTC
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 17:13:43 UTC
Created attachment 93154 [details]
Anaconda dump file

Comment 2 David Tonhofer 2003-07-25 17:32:41 UTC
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-26 03:09:27 UTC
Did you have preexising RAID devices on the system before you reinstalled?

Comment 4 David Tonhofer 2003-07-29 08:59:32 UTC
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-05 03:20:21 UTC
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.