Bug 80855 - Installer crashed at partition section
Installer crashed at partition section
Product: Red Hat Linux
Classification: Retired
Component: anaconda (Show other bugs)
i686 Linux
medium Severity medium
: ---
: ---
Assigned To: Michael Fulbright
Mike McLean
Depends On:
  Show dependency treegraph
Reported: 2002-12-31 21:53 EST by Chris Darsey
Modified: 2007-04-18 12:49 EDT (History)
0 users

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Last Closed: 2003-01-10 02:17:27 EST
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Attachments (Terms of Use)
Kickstart config (7.54 KB, text/plain)
2002-12-31 21:55 EST, Chris Darsey
no flags Details
Anaconda dump file (51.48 KB, text/plain)
2002-12-31 21:59 EST, Chris Darsey
no flags Details

  None (edit)
Description Chris Darsey 2002-12-31 21:53:10 EST
Description of problem:
Using 'linux ks=floppy' on boot to install RH 7.3.  Attached is the kickstart 
file I am using (personal data removed; Ok, just realized Python dump inserts 
data in file :-/).  Stepped through GUI screen (problem occurs with text mode 
also).  Crashed happens after mouse options and before partition setup.  When 
I click the Debug button, "KeyError: hda1" is displayed.  System had same 
installation before hand.

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

How reproducible:

Steps to Reproduce:
1. Boot from CD #1.
2. At boot prompt, type 'linux ks=floppy'. Floppy should have ks.cfg.
3. Click Next button in GUI.
4. Watch installer crash...

Actual Results:  System requires reboot.

Expected Results:  Haven't performed a KS install before.  I would think Disk 
Druid would appear with my partioning information.

Additional info:

Since output was sent to console, I cannot add the error messages displayed.
Comment 1 Chris Darsey 2002-12-31 21:55:48 EST
Created attachment 89021 [details]
Kickstart config

This is the KS config I was using.  Personal info has been removed.
Comment 2 Chris Darsey 2002-12-31 21:59:30 EST
Created attachment 89022 [details]
Anaconda dump file
Comment 3 Michael Fulbright 2003-01-02 17:22:28 EST
There are no partition tables on the drives according to the kernel partition
scan, and you have 'zerombr yes' commented out.

You need to enable this line so it can put a clean (empty) partition table on
drives w/o them.
Comment 4 Chris Darsey 2003-01-02 19:54:24 EST
Yes, I originally used 'zerombr yes', which produce the initial error.  
Afterwards, I did change some things around to see if I could get it to work.  
When I used 'zerombr yes', I had the following:

clearpart --all 
part raid.1 --onpart hda1 --badblocks
part raid.7 --onpart hdb1 --badblocks
part raid.2 --onpart hda2 --badblocks
part raid.8 --onpart hdb2 --badblocks
part raid.3 --onpart hda3 --badblocks
part raid.9 --onpart hdb3 --badblocks
part raid.5 --onpart hda5 --badblocks
part raid.11 --onpart hdb5 --badblocks
part raid.6 --onpart hda6 --badblocks
part raid.12 --onpart hdb6 --badblocks
raid / --fstype ext3 --level=RAID1 raid.2 raid.8
raid /boot --fstype ext3 --level=RAID1 raid.1 raid.7
raid swap --fstype swap --level=RAID0 raid.5 raid.11
raid /home --fstype ext3 --level=RAID1 raid.6 raid.12
raid /var --fstype ext3 --level=RAID1 raid.3 raid.9

Other than 'zerombr' and 'clearpart --all', the rest was produced by Anaconda.
Comment 5 Jeremy Katz 2003-01-10 02:17:27 EST
This should be handled somewhat better in 8.0 and even a little bit better in

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