Re: New Debian Install - HELP!

["Kerry Hoath" <kerry@gotss.net>]

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.