Hello all,
I was about to give up for the time being, but since I got so many replies, I will give it another shot. I will study all the posts tonight, but for now to answer Old-Polack:
HP workstation X4000
My model variant has:
dual Xeon 2.4 MHZ 860 chipset 1024 Gb ECC RAM (incl. PCI 64-bit Hublink (P64H))
Phoenix Bios 4.0 Release 6.0 updated to latest revision dated 03-04-2003.
One AGP 8X slot with Quadro4 900 XGL Pro card (full slot)
two Ultra 160 SCSI controllers, (I added USB 2.0 to PCI slot)
if anyone is curious about this ancient artifact, lol! here is a link:
http://h20000.www2.hp.com/bizsupport/TechSupport/DocumentIndex.jsp?contentType=SupportManual&lang=en&cc=us&docIndexId=64180&taskId=101&prodTypeId=12454&prodSeriesId=76193#1
Years ago, a teacher of linux helped me install 2 linux OS and windows on my own computer, and explained to me how to deal with: grub error 18 : Selected cylinder exceeds maximum supported by BIOS
This error is returned when a read is attempted at a linear block address beyond the end of the BIOS translated area. This generally happens if your disk is larger than the BIOS can handle.
Older BIOSes use CHS rather than LBA to address the boot disk. The disk address of the kernel that is stored in the boot sector has only 10 bits for the cylinder number. Therefore the kernel and initrd, if used, must lie entirely below the 1024 cylinder boundary. Failure to observer this restriction gives rise to the error.
To prevent this occuring create a /boot partition of, say, 100MB at the start of the disk and store your Grub configurations, kernels and initrd images in it. You can then create your root partition where you like, even on a different disk.
see: http://mankin.org.uk/howto/grubErrors.html
This workstation
Now we have a starting point that we can relate to. I actually have a couple of machines that seem to predate yours, and the BIOS in them has a place where you can choose whether to use CHS or LBA to address the hard drives. Choosing CHS gave a drive size limit of 8 GB, while LBA gave a drive capacity limit of 127/136 GB. (Depending on how you define GB) An add in controller card, (purchased later) had its own built in BIOS, that allowed for LBA48 addressing, and on initial boot up, gave a message that it could control all the drives present, and asked if I would like to allow that option. I did, and drive limits sort of disappeared.
"What does that have to do with my machine?" you may ask. Check in your BIOS for a section that deals with hard drive addressing, and look for options, LBA, or Large Disk Addressing. Different BIOS use different terms, but most after 1997 do have such choices available. According to HP, that model came with a 36 GB hard drive, which would indicate that it had a BIOS capable of being set to LBA addressing. That alone should allow booting from either of the two smaller hard drives, or any other drive up to at least 127 GB, without the need for boot partitions.
The 500 GB drive may or may not require a single boot partition, depending on what is available for BIOS upgrades.
I again digress here, to recount another personal experience with an earlier computer I purchased from Sony in 1997. It had a Phoenix BIOS with a 8 GB hard drive limit. I called Phoenix and asked about an upgrade to use larger hard drives. They informed me that their BIOS at that time supported 127/136 GB drives, was licensed to Sony, and the drive size restriction was artificially set, by Sony's crippling of the BIOS, by removing the LBA option from the selection list. As part of the licensing agreement, any BIOS upgrades had to come from Sony, as they (Phoenix) were prohibited from interfering with their licensee's wishes.
I contacted Sony about an upgrade, and was told there would be none that increased the hard drive limit. I was then told that if I wanted larger drives in my machine, I would have to buy a newer version Sony machine. My machine was, at that time, three months old. Not good PR on Sony's part. I've never bought another Sony product since.
The Sony motherboard was from Intel, so I searched for BIOS upgrades from them, and found one that allowed for LBA addressing, but it wouldn't install on the Sony motherboard due to firmware restrictions, where only official Sony BIOS upgrades were allowed. Short version of the story is that I learned to use a hex editor, compared the BIOS upgrade files from Intel and Sony, then edited the Intel BIOS upgrade to identify itself as an official Sony BIOS upgrade, after which it did upgrade the BIOS on the Sony motherboard, and I got the larger hard drive capacity I sought. There are ways, and then there are other ways.

Back to your 500 GB drive. If there are no newer BIOS upgrades available for that machine, and you are not comfortable with forging one from someone else with a hex editor, there are add in RAID/Controller cards (as mentioned above) that have their own BIOS that will allow the full use of larger drives. I recently purchased such a card for my current machine that is all SATA. The card supplies four IDE controllers, which allows up to 8 IDE devices to be installed, and uses LBA48 addressing for full access to the largest IDE drives made. Said card cost me $34.97 including shipping, from Newegg, and may be even cheaper elsewhere.
Specifically, this card is from HighPoint and carries the name RocketRaid 454. It fits a standard PCI slot, and can be set to RAID 0, 1, 10, 5, or JBOD, if you don't want an actual RAID and just want to connect multiple independent hard drives. Before SATA became the standard for new hard drives, this was a very expensive card, mostly targeted at industry and gamers. Now it's become a clearance item. The box has a printed oval on the front that states, "Linux Supported!" Considering the copyright on the box is from 2003, that's impressive in itself.

Last, there is the no cost, single boot partition, that holds all of your kernels and initrd images, for all of your installations, and a single grub installation to the MBR that controls the booting of all of them from a single menu.lst. Note that a
boot partition is not necessarily a
/boot partition. I have a boot partition on one of my internal hard drives, and on each of my external hard drives, in case I move one of them to another machine and want to boot one of the OS installed on that drive. I don't actually need them, but they are good insurance, as I can always boot from either the / partition of an installation, or from the boot partition. The boot partitions are completely autonomous, and do not get mounted to any single installation at run time. No matter which hard drive is designated as the boot drive, the kernels and initrd images for each installation can always be found on (hd0,0), the partitions to be mounted as / are all labeled, and the labels are used in the individual boot stanzas, which avoids the problems you are currently having.
[root@fatman ~]# grub Probing devices to guess BIOS drives. This may take a long time.
GNU GRUB version 0.97 (640K lower / 3072K upper memory)
[ Minimal BASH-like line editing is supported. For the first word, TAB
lists possible command completions. Anywhere else TAB lists the possible
completions of a device/filename. ]
grub> find /grub/stage2 find /grub/stage2
(hd0,0)
(hd1,0)
<--- My three boot partitions (hd2,0)
grub> find /boot/grub/stage2find /boot/grub/stage2
(hd0,0)
(hd0,6)
(hd0,7)
(hd0,8)
(hd0,12)
(hd0,13)
(hd0,14)
(hd0,16)
(hd1,0)
(hd1,7)
(hd2,0)
(hd2,2)
<--- The installations that can be booted from the boot partition (hd2,4)
(hd2,5)
(hd2,6)
(hd2,8)
(hd2,9)
(hd2,10)
(hd2,14)
(hd2,15)
grub> quitquit
[root@fatman ~]# Note that the boot partitions are also included in the second list, though there is no actual OS on any of them. This is caused by a link, named boot, that points to the partition itself, that aids in the setup of the partition. Each time I install an OS, before rebooting, I copy the new /boot directory to the boot partition. The link causes the system to say that /boot already exists and to ask if the link should be overwritten, or if the copied directory should be renamed. I rename the new copy of /boot to reflect the OS it came from. This keeps the individual kernels and initrd images for each installed OS separate from each other.
I then edit the master /grub/menu.lst that resides on the boot partition, copying the first stanza of the individual installation's menu.lst, then editing it so that it searches for the kernel and initrd image on
(hd0,0)/<installation-name>/<whatever>.
A typical stanza would look like this;
title 64-RC BP
kernel (hd0,0)/64RC/vmlinuz BOOT_IMAGE=64-RC root=LABEL=64RC nokmsboot acpi=on resume=LABEL=swap2000 splash=verbose vga=791
initrd (hd0,0)/64RC/initrd.img
...or this;
title KDE test2000 BP
kernel (hd0,0)/test2000/vmlinuz BOOT_IMAGE=KDE_test2000_BP root=LABEL=test2000 acpi=on resume=LABEL=swap2000 splash=verbose vga=791
initrd (hd0,0)/test2000/initrd.imgThere are no long, confusing UUID= numbers, only easy to recognize LABEL= names. To paraphrase, "One boot partition, to rule them all."
Now, about those partitions on your drives... I have a few more than you, and other than the single boot partition at the beginning of each of the three drives mentioned above, they are either OS
/ partitions, or
data partitions, with the exception of having one
/home partition, for this 64 bit test installation, which I usually don't separate from the
/ partition. All the personal data that is usually collected in
/home/<user> in my case goes to data partitions mounted on
/home/polack/Documents, and
/home/polack/Documents2. I can mount those partitions in the same place on each installation so my personal data is always available from whichever OS I choose to boot.
Music and videos are also stored on separate data partitions, and likewise always mounted in the same place on each installation, using the
same /etc/fstab for each installation. The only edit is for the proper
LABEL=<whatever> for the individual
/ partition being mounted for each OS. All my data, of every type, is always in the same relative place no matter which OS I'm currently running, because I took the time to organize it properly, like the partitions themselves.
[root@fatman ~]# fdisk -lDisk /dev/sdb: 750.2 GB, 750156374016 bytes
255 heads, 63 sectors/track, 91201 cylinders, total 1465149168 sectors
Units = sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes
Disk identifier: 0x2db1883a
Device Boot Start End Blocks Id System
/dev/sdb1 63 208844 104391 83 Linux
/dev/sdb2 208845 12225464 6008310 82 Linux swap / Solaris
/dev/sdb3 12225465 72244304 30009420 83 Linux
/dev/sdb4 72244305 1465144064 696449880 5 Extended
/dev/sdb5 72244368 272253554 100004593+ 83 Linux
/dev/sdb6 272253618 670713749 199230066 83 Linux
/dev/sdb7 670713813 731278799 30282493+ 83 Linux
/dev/sdb8 731278863 811378889 40050013+ 83 Linux
/dev/sdb9 811378953 1045767239 117194143+ 83 Linux
/dev/sdb10 1045767303 1280155589 117194143+ 83 Linux
/dev/sdb11 1280155653 1465144064 92494206 83 Linux
Disk /dev/sdc: 2000.4 GB, 2000398934016 bytes
255 heads, 63 sectors/track, 243201 cylinders, total 3907029168 sectors
Units = sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 4096 bytes
I/O size (minimum/optimal): 4096 bytes / 4096 bytes
Disk identifier: 0x18eee7ae
Device Boot Start End Blocks Id System
/dev/sdc1 2048 2099199 1048576 83 Linux
/dev/sdc2 2099200 18876415 8388608 82 Linux swap / Solaris
/dev/sdc3 18876416 81790975 31457280 83 Linux
/dev/sdc4 81790976 3907029167 1912619096 5 Extended
/dev/sdc5 81793024 176164863 47185920 83 Linux
/dev/sdc6 176166912 281024511 52428800 83 Linux
/dev/sdc7 281026560 385884159 52428800 83 Linux
/dev/sdc8 385886208 805316607 209715200 83 Linux
/dev/sdc9 805318656 857747455 26214400 83 Linux
/dev/sdc10 857749504 910178303 26214400 83 Linux
/dev/sdc11 910180352 962609151 26214400 83 Linux
/dev/sdc12 962611200 1172326399 104857600 83 Linux
/dev/sdc13 1172328448 1382043647 104857600 83 Linux
/dev/sdc14 1382045696 1803573247 210763776 83 Linux
/dev/sdc15 1803575296 1897947135 47185920 83 Linux
/dev/sdc16 1897949184 1939892223 20971520 83 Linux
Disk /dev/sdd: 2000.4 GB, 2000398934016 bytes
255 heads, 63 sectors/track, 243201 cylinders, total 3907029168 sectors
Units = sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 4096 bytes
I/O size (minimum/optimal): 4096 bytes / 4096 bytes
Disk identifier: 0xbbcb054b
Device Boot Start End Blocks Id System
/dev/sdd1 2048 4196351 2097152 83 Linux
/dev/sdd2 4196352 2101348351 1048576000 83 Linux
Disk /dev/sda: 1000.2 GB, 1000204886016 bytes
255 heads, 63 sectors/track, 121601 cylinders, total 1953525168 sectors
Units = sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes
Disk identifier: 0x0000d21c
Device Boot Start End Blocks Id System
/dev/sda1 63 626534 313236 83 Linux
/dev/sda2 626535 16820054 8096760 82 Linux swap / Solaris
/dev/sda3 16820055 114495254 48837600 83 Linux
/dev/sda4 114495255 1953520064 919512405 5 Extended
/dev/sda5 114495318 329332499 107418591 83 Linux
/dev/sda6 329332563 534434354 102550896 83 Linux
/dev/sda7 534434418 596943269 31254426 83 Linux
/dev/sda8 596943333 659452184 31254426 83 Linux
/dev/sda9 659452248 721961099 31254426 83 Linux
/dev/sda10 721961163 784470014 31254426 83 Linux
/dev/sda11 784470078 994198589 104864256 83 Linux
/dev/sda12 994198653 1623368249 314584798+ 83 Linux
/dev/sda13 1623368313 1685893229 31262458+ 83 Linux
/dev/sda14 1685893293 1749366044 31736376 83 Linux
/dev/sda15 1749366108 1816485614 33559753+ 83 Linux
/dev/sda16 1816487663 1889887982 36700160 83 Linux
/dev/sda17 1889892080 1953520064 31813992+ 83 Linux