Hardware humbug

[unixronin]

To summarize the underlying problem, babylon5's Linux install is ancient and clogged with cruft, and its SCSI hard disks are dying rapidly.

Simple solution:  Install an inexpensive SATA controller and a new mirrored pair of SATA disks.

Well, by swapping controllers around so that the existing SCSI disks aren't the first devices, I can get the machine — which is built on an Asus A7V333 motherboard — to boot from a SCSI CDROM which it will not, as a general matter of course, condescend to boot from.  From that CDROM I can boot a Gentoo liveCD, set up the new disk, install Gentoo, build a kernel, set up grub, etc, etc, etc, all with relatively little issue (aside from the part where I typo'd "-mtune=athlon-xp" as "-mtune=athlonxp" which resulted in gcc declining to compile anything).

There's just one problem.  Try as I might, this motherboard WILL NOT boot from SATA.  Leaving me squarely behind the eight ball for upgrading the machine, I think, unless I hold my nose and suffer with PATA.  It'd be cheaper to buy a new motherboard, CPU and RAM than to buy a pair of new SCSI disks.

(Update 2355:  I didn't even have much luck with PATA so far.  I even tried dropping in my one good spare PATA disk, an 80GB Seagate Barracuda of uncertain age, just to put a bootloader on its MBR to boot the SATA disk. No joy; grub would install but wouldn't load.)

Comments

SCSI/SATA boot order

[ewen]

Possibly you're already aware of this, but just in case: both LILO and grub need to guess what the disk order will be in the BIOS in order to figure out what they need to put into the initial boot loader (MBR, stage0, etc) to get it to load the next stage from the correct disk through the BIOS. These guesses work reasonably well when you have only one type of disk in the machine. But if you have multiple types of disks in the machine it's pretty hit and miss. IIRC the Adaptec BIOS will tend to register its disks as 0x80 ("C:" in DOS) if it is told to be bootable, and something later if it is told not to be bootable. SATA/PATA end up in interesting orders depending on the main BIOS disk scan order and boot order, but since the Adaptec BIOS processes the BIOS disk tables last its view of the world wins. IME the LILO/grub installer guesses don't seem to know about all these nuances.

With LILO I would put something like:

disk=/dev/sda
bios=0x80
disk=/dev/sdb
bios=0x81

which would force LILO to associate specific BIOS device IDs with particular Linux SCSI IDs. In this case 0x80 is the first boot device as ordered by the BIOS scans, so it's a matter of telling LILO which one it will be.

IIRC the equivalent in grub is /boot/grub/device.map, which is auto-created by default (install-grub), but I've not had to deal with this sort of boot issue with grub. (The machines I had with multiple types of devices ended up being simplified down to just SATA before I got to installing grub.)

Ewen

Re: SCSI/SATA boot order

[unixronin.livejournal.com]

Actually, in this case the situation's a little more complex than that, because the Slackware install was on a set of RAID1 mirrored devices, so boot was from device 0901 (/dev/md/1).

Grub probes the BIOS to map devices, yes. I've been thinking about the problem overnight and I think that with any luck, I MAY have a solution. Among other things, I've realized that part of my problem is grub doesn't understand JFS yet, so I'm going to be forced (for the first time ever) to use a separate ext3 /boot partition. I also may have forgotten to mark my boot partition on the SATA disk as active.

So, I'm going to try it all again. But not today. Especially since I CANNOT make the machine boot from the SCSI CDROM if there is a working and bootable SCSI disk on the same controller and it's one of the first two disks the BIOS sees. Oddly, if none of the bootable SCSI disks is among the first two visible devices, it's quite happy to boot from the SCSI CDROM.

Well ... OK, maybe today. Because another SCSI disk just failed, and I no longer have a boot mirror. So now I'm under time pressure before the remaining disk (which is actually the oldest) fails too.