Bug 14608 - Kickstart install may fail on disks with >1024 cylinders
Summary: Kickstart install may fail on disks with >1024 cylinders
Status: CLOSED RAWHIDE
Alias: None
Product: Red Hat Linux
Classification: Retired
Component: installer   
(Show other bugs)
Version: 6.2
Hardware: i386 Linux
high
medium
Target Milestone: ---
Assignee: Jeremy Katz
QA Contact: Brock Organ
URL:
Whiteboard:
Keywords:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2000-07-25 10:52 UTC by Paul Flinders
Modified: 2007-03-27 03:33 UTC (History)
0 users

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2001-07-02 15:06:24 UTC
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)

Description Paul Flinders 2000-07-25 10:52:56 UTC
I am trying to write a kickstart configuration file
for a small cluster of servers that I am building.

Each machine has a 20G Maxtor hard drive which has
a translated CHS of 2491/255/63

I set the partitions up in ks.cfg as follows

part / --size 1536
part swap --size 2048
part /usr3 --size 7969
part /usr2 --size 7969

However the partition table on the disk had the
partitions in reverse order with the result that
the root partition was well above the 1024 cylinder
limit and the installation wouldn't boot.

It is somewhat counter-intuitive that the partition
order on the disk does not follow the order given
in the configuration file (in fact changing the
file order doesn't have any effect on the on-disk
layout) and placing the partition containing the
kernel above cylinder 1024 is a definate bug.

In the end I use the %post script to create the
two 8G partitions. Even then the swap partition
ended up as /dev/hda1 (and had the LILO boot sector
installed) although / was listed first in the
config file.

The 1024 cylinder problem should "go away" with
new versions of lilo but the fact that one cannot
control the order in which partitions are created
seems to be something of a problem. The --onpart
switch is not much use to me as the install needs
to work on a new machine which has no partition table.

Comment 1 Michael Fulbright 2000-07-25 13:54:05 UTC
Brock please try to verify, and if this is a problem please test against latest
internal version to see if it is corrected.

Comment 2 Brock Organ 2000-08-15 18:27:29 UTC
Verified problem against 6.2 & Winston RC-1 ...

Comment 3 Michael Fulbright 2001-04-11 15:42:28 UTC
Will address in code rewrite.

Comment 4 Michael Fulbright 2001-06-27 16:44:29 UTC
How is our status on this Jeremy?

Comment 5 Jeremy Katz 2001-07-10 03:12:55 UTC
Shouldn't be able to happen with the new code base.  We always place the "boot"
partition as much at the start of the drive as we can (either /boot or /,
depending on if /boot exists as a separate partition or not)


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