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 problems: 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 fine. 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.
Brock please try to reproduce in test lab and I will have a look at it.
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 :)
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 :-).
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 items: 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... :-).
thanks for the clarification! The problem was verified, LILO doesn't run properly: (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)
This defect is considered MUST-FIX for Florence Gold release
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.