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

[tomatoe333.livejournal.com]

I don't know the fix, but the problem is _probably_ that the external SATA controller appears to the system as an external SCSI controller. So you have that "SCSI" controller in addition to the SCSI controller on the motherboard.

I'd say your best bet is to try to get to a configuration where the onboard SCSI is disabled, and tell the BIOS to boot from "external SCSI controller".

[unixronin.livejournal.com]

There is no onboard SCSI. There's one SiI3124 four-port SATA controller and one Adaptec AHA29160 (previously two, but I ran into crippling IRQ-shortage issues when I added the SATA controller).

If the AHA29160 is the first controller, the machine will boot from disks attached to that controller, but will boot from the CDROM attached to it (or, formerly, to the second SCSI controller) only if it finds no SCSI disks. If the SATA controller is first, then it refuses to boot from SATA (either disk or CD/DVD), ignores the SCSI disks because they're not on the first controller, then finds — and boots from — the SCSI CDROM.

So, basically, if there's a bootable SCSI disk first up, it'll boot from it. If there's no bootable SCSI disk in the first slot, it'll eventually find the SCSI CDROM. But it doesn't consider SATA devices bootable, period, and doesn't appear to even see them.

[tomatoe333.livejournal.com]

Sil? Hmmm, I remember those being REALLY crappy controllers...

If there is an on-board BIOS/firmware, get into that, and tell it that one of the SATA drives is drive C:. That'll get it to be bootable.

If there is no BIOS/firmware, therein lies the problem.

[unixronin.livejournal.com]

Firmware in the SiI3124? Hmm ..... that possibility hadn't occurred to me. I may be able to do that.

(Update: No, the 3124 does have onboard firmware, but it can't do that ... it's solely for setting up RAID configurations.)

[bikergeek.livejournal.com]

the other option would be to have a cheap PATA disk for /boot, and boot from that long enough to install the SATA drivers to read everything else?

[unixronin.livejournal.com]

It's a possibility, I suppose. Most likely all it really needs to have on it is grub. I'm guessing I could probably make that work with a little tiny floppy-sized CompactFlash card (wouldn't even need to be 1MB) and a PATA adapter. The adapter would probably cost more than the flash card.

Update: Actually, it looks as though I'd have to go flash card on CF-to-2.5" adapter on 2.5"-to-3.5" adapter. It would be fairly cheap, about $20 plus a CF card, but it might work. The Heath-Robinson factor is climbing ... but I suppose it would be kind of a cool hack, if it worked.

[jmkelly.livejournal.com]

SCSI is so 20th-century....

[unixronin.livejournal.com]

Maybe so, but based on this evening's experiences I think this machine would sooner go to meet its ancestors than boot from a SATA device. (I even tried installing a spare PATA disk of unknown age, solely to install a bootloader on its MBR. That didn't work either.) And it's not as though the motherboard is even that old - 2003 or so.

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.