> OK, but isn't the only limit in regard to the BIOS the 1024 cylinder > limit? Someone pointed out that this is roughly 8G. Since I always > booted off a partition that was past the 30G mark it doesn't strike me > as if there is a BIOS issue....unless someone digs up yet another mark > that may play a role. So if it is a BIOS 1024 cylinder issue it ought to > have never worked. There are two normal limits - 1024 cylinders, which is rarely a problem on newer boxes and often not older ones (a good guide is that this is generally fixed by the EDD extensions to the BIOS which are the same ones that give a BIOS standard "boot order" settings for disks, so if you can boot off drive C, D, E, ... its probably not got this limit) The second limit you sometimes hit in the BIOS nowdays is around 32GB and is caused by older BIOSes being confused by the larger LBA disks. The disk lies to the BIOS that it is 32GB in size and the boot area must all be below 32GB. The OS (Linux, Windows, ...) once booted doesn't use the BIOS services and tells the disk to stop lying about its size. Its a jumper on some disks but not one thats likely to be a problem unless you set that jumper yourself. GRUB is used by just about every Linux OS (and most other non-Windows OS on the planet) on all PC type systems 32 or 64bit. Its pretty reliable unless wrongly configured. Your comments about the raid are wrong also btw. For software fake RAID (most RAID today) you usually can't boot from a RAID volume directly. For RAID1 the system normally boots by putting the boot data on the first disk of the RAID (or optionally onto both). The BIOS will only load from the boot volume so this works fine. If you've got BIOS fakeraid doing RAID0 or RAID0+1 striping then it all gets extremely ugly. In that case the preferable approach is to use the Linux raid formats directly not the BIOS ones. That can be a pain if you've got mixed Windows/Linux on one disk. Alan
