Bug 14875 - Problems with partitioning algorithm
Summary: Problems with partitioning algorithm
Alias: None
Product: Red Hat Linux
Classification: Retired
Component: anaconda
Version: 7.0
Hardware: i386
OS: Linux
Target Milestone: ---
Assignee: Michael Fulbright
QA Contact:
Whiteboard: Florence Beta-3
Depends On:
TreeView+ depends on / blocked
Reported: 2000-07-31 12:40 UTC by Jos Vos
Modified: 2008-05-01 15:37 UTC (History)
0 users

Clone Of:
Last Closed: 2001-01-18 18:34:50 UTC

Attachments (Terms of Use)

Description Jos Vos 2000-07-31 12:40:01 UTC
The partitioning scheme doesn't work for some cases (this is the case since
long, but I just never reported it, sorry for that).  These are the

Problem 1:

The largest partition is made the primary partition, the rest is put in an
extended partition.  One would expect the partition that contains /boot to
become the primary partition.  Now there is a bigger chance that the kernel
is put on a place the BIOS can't access.  I tested the following scenario,
which indeed went wrong:

- Non-Linux partition at the beginning of the disk (hda1)
- About 150 MB left in first 1024 cylinders.
- Installing RH 7.0 beta 5 with kickstart, asking for / of 100 MB and some
other partitions.

Now /usr was installed as hda2, / became hda5 (on cylinders > 1024) and at
the end LILO failed and the system was not bootable.  If hda2 was made /,
it would have fit in the first 1024 cylinders and all would have worked

Problem 2:

Furthermore, if you choose to put LILO not in the MBR, it is put in the
partition where /boot is (didn't test with separate / and /boot
partitions), which just doesn't work when /boot is in a logical partition,
AFAIK.  This is almost always the case, as normally /usr or /home are much
larger than / or /boot, so installing LILO in a partition almost never
works, I think.

Comment 1 Michael Fulbright 2000-07-31 14:38:12 UTC
Brock please try to reproduce in test lab and I will have a look at it.

Comment 2 Brock Organ 2000-07-31 19:20:39 UTC
hmmm ... I'm not seeing the same behavior (using TUI ddruid) ... 

starting with only a non-linux partition on hda1, and using disk druid to add
new partitions (this is above the 1024 cyl limit)

Issue 1) /usr became hda2 while /boot became hda5:

in our test lab, creating /usr, / and /boot partition (in that order) resulted
in ddruid placing them as /usr -> hda5, / -> hda6, /boot -> hda2

Did your partition table contain any other entries besides hda1 ..?

Issue 2) LILO in /boot partition when /boot is extended

I am not sure this is an issue since this option exists for situations where
other OS loaders may occupy the MBR, and LILO needs to peacefully coexist ...

Please let me know if these answers are getting at the problem you suggested
above :)

Comment 3 Jos Vos 2000-07-31 20:23:06 UTC
Issue 1)

No, my partition table contained one non-Linux partition (not sure if it was
hda1, but I think so).

-  I only tested it with kickstart.  Does the order matter (either manually or
listed in kickstart)?
-  Is your /usr indeed larger than /boot (I guess so, but just to be sure...)?
-  I can try again tomorrow and send you the exact partition info, kickstart
file, etc.

Maybe the problem only exists with kickstart?  I just installed some 6.2
systems, all with / in
hda9 and /usr was hda1, this has been so forever, unfortunately.  Can you try
with kickstart?

Issue 2)

Assuming /boot is a primary partition, the LILO bootblock really should be
installed there, as "normal" bootloaders can only handle bootblocks in primary
partitions.  But if issue 1 is solved, and the algorithm defines that the
bootblock will be put in the partition with /boot, issue 2 is solved
automatically :-).

Comment 4 Jos Vos 2000-08-01 12:07:42 UTC
I tested some more things: it appears that it works correct if you have a
separate /boot partition, but it doesn't work correct if you have /boot included
in the / partition.  So, there should be a check whether there is a separate
/boot partition and a primary partition should be assigned to / if this is not
the case. Issue 2 will be solved automatically then, as either /boot or / become
a primary partition.

My failure scenario is: start with

Disk /dev/hda: 255 heads, 63 sectors, 1245 cylinders
Units = cylinders of 16065 * 512 bytes

   Device Boot    Start       End    Blocks   Id  System
/dev/hda1   *         1      1000   8032468+   b  Win95 FAT32

So, there is approx. 190 MB left in the first 1024 cylinders (I use a / of 100
MB). Then I install with ks.cfg, limited install (@ Network Server), relevant

zerombr no
clearpart --linux
part swap --size 100
part / --size 100
part /var --size 200
part /usr --size 300
lilo --location partition

Afterwards, the partition table looks like:

Disk /dev/hda: 255 heads, 63 sectors, 1245 cylinders
Units = cylinders of 16065 * 512 bytes

   Device Boot    Start       End    Blocks   Id  System
/dev/hda1   *         1      1000   8032468+   b  Win95 FAT32
/dev/hda2          1001      1039    313267+  83  Linux
/dev/hda3          1040      1245   1654695    5  Extended
/dev/hda5          1040      1065    208813+  83  Linux
/dev/hda6          1066      1078    104391   82  Linux swap
/dev/hda7          1079      1091    104391   83  Linux

And lilo complains during installation about wrong cylinders, as it tries to
install the bootblock on /dev/hda7 (all sizes, except swap, are different, so
you can easily recognize the partitions :-)).

I hope this is detailed enough... :-).

Comment 5 Brock Organ 2000-08-02 17:18:24 UTC
thanks for the clarification!  The problem was verified, LILO doesn't run

(in the chrooted /mnt/sysimage:)
% /sbin/lilo
Warning: device 0x0307 exceeds 1024 cylinder limit
Fatal: geo_comp_addr: Cylinder number is too big (1085 > 1023)

Comment 6 Glen Foster 2001-01-11 21:13:34 UTC
This defect is considered MUST-FIX for Florence Gold release

Comment 7 Michael Fulbright 2001-01-18 18:34:46 UTC
It is now possible to specify a partition should be allocated as a primary
partition when using kickstart. I did not see these problems occuring in
interactive mode.  The kickstart interface allows more flexibility to the user,
but at the expense that sometimes its possible to have things not work out
perfectly w/o some intervention.

I would recommend trying the option to force /boot to be a primary partition.

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