I can answer one of your questions easily enough. "What the hell does lilo have to do with raid?" Quite a lot actually. As you probably know; unless you have bios support and devicemapper set to handle those bios fakeraid situations you can only boot from a raid1 array, i.e. 1 or more drives beeing mirrored. Yes 1 drive is a valid raid1 array with no redundancy. On my raid box, I have 7 drives; each having a 200 meg /boot partition on them. If I tell Lilo that /boot is in fact on an md device it will insure that _all_ of the boot sectors on the raid devices are updated when I run Lilo, all 7 of them. It can also place the same code on all 7 mbrs so that if a disk fails and I pull it out; the system will still boot. RAID isn't much good if the system it is running on fails to boot with the loss of a drive. Of course the rest of the partitions on that box are raid5 and there's a raid10 section for swap but it is important that Lilo keeps the boot information consistant across all drives. The other thing Lilo can do is mark all boot sectors as using bios drive 0x80 on all drives to boot the operating system. This means that if drive 0 (0x80 usually) fails, drive 1 becomes drive 0 and therefor 0x80. To load sectors from disks at boot time the bios uses int 0x13 and loads the drive letter into the dl register. numbers 0 through 0x7f are considered floppy drives etc, drives above 0x80 (or 128 decimal) are the first second 3rd etc hard disks. Modern bioses allow you to set the boot order so that whatever drive you like shows as 0x80, either hard disks or usb external hard disks if you like. Whilst modern bioses use LBA and soe does grub, Linux needs to know which drive it is pulling the boot code from for example the first or second drive etc. Drives can be detected in a different order in Linux as to that in Windows, which is why there are mechanisms to override the /dev/xdx mappings to bios drive numbers. Note that Linux treats IDE drives as scsi if you are using libata to control your drives; this has been true for most chipsets since kernel 2.6.12 or so. /dev/hdx is used for chips that are not under libata control. libata is the new device framework that supports amung other things, hotplug sata, sata power management and command queuing, and advanced drive power management. If you upgrade from a system that used the old disk drivers your drives will change names from /dev/hdx to /dev/sdx. If everything goes correctly which it often does, you get /dev/hda to /dev/sda however if you only hav /dev/hdc it becomes /dev/sdb as the sd a through z increase monotomically with each drive detected. Note that with udev and initial ram disks and the like present in most modern Linux distributions only a subset of device nodes exist in /dev/.static and udev creates devices as the kernel initializes hardware and populates an in memory copy of /dev You can get around some of this problem in lilo by specifying devices by there major and minor numbers, root=0x0801 however it is much cleaner to fix the mappings in the boot loader. There is no way of getting around fiddling in bios config however there are accessible bioses; those that can send bios setup out through a serial port or similar. Problem is they only work on a subset of system boards, however googling for openbios might be of value. There is also now a PCI version of the pc-wiesel card that will send video output through a serial port; they're not cheap though. I am lucky enough to get my wife to read bioses to me when necessary. Regards, Kerry.
