Bug 14608 - Kickstart install may fail on disks with >1024 cylinders
Kickstart install may fail on disks with >1024 cylinders
Status: CLOSED RAWHIDE
Product: Red Hat Linux
Classification: Retired
Component: installer (Show other bugs)
6.2
i386 Linux
high Severity medium
: ---
: ---
Assigned To: Jeremy Katz
Brock Organ
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2000-07-25 06:52 EDT by Paul Flinders
Modified: 2007-03-26 23:33 EDT (History)
0 users

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


Attachments (Terms of Use)

  None (edit)
Description Paul Flinders 2000-07-25 06:52:56 EDT
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 09:54:05 EDT
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 14:27:29 EDT
Verified problem against 6.2 & Winston RC-1 ...
Comment 3 Michael Fulbright 2001-04-11 11:42:28 EDT
Will address in code rewrite.
Comment 4 Michael Fulbright 2001-06-27 12:44:29 EDT
How is our status on this Jeremy?
Comment 5 Jeremy Katz 2001-07-09 23:12:55 EDT
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.