I am struggling with a Dell PowerEdge that has 2 SCSI disks hanging
off the on-board controller and SATA disks connected to a SiL 3112
based PCI adaptor.  It boots from SCSI and the DOM0 is installed on the
SCSI disks.  I use NetBSD 3.1_STABLE and Xen2.

When the machine boots the SCSI BIOS is run first and registers.  The
SATA BIOS is run after that and registers the SATA disks.  Therefore I assume
that the SCSI disks are registered as BIOS disks 0x80 and 0x81 and the SATA
disk as BIOS disk 0x82.

The first annoyance is that the DOM0 kernel thinks wd0 is the boot device
and can't find the root fs on it.  It seems to me that the call to
determine the BIOS geometry from the bootinfo in matchbiosdisks() fails.

When I run grub(1) from the command line it comes up with the following
drive mapping:

(hd0)   /dev/wd0d
(hd1)   /dev/sd0d
(hd2)   /dev/sd1d

This is to be expected, because grub(1) first probes the IDE/ATA disks and
then the SCSI disks.  (I believe it fails to probe the ld(4) disks on NetBSD.)

What it not so obvious is that grub(1) ignores the device.map file unless
invoked with "--device-map=/grub/device.map".

Of course, I can use the device.map file to tell it the mapping i want:

(hd0)   /dev/sd0d
(hd1)   /dev/sd1d
(hd2)   /dev/wd0d

However, when I break out of the boot menu that grub presents after loading
the second stage it seems to use the following drive mapping:

(hd0)   sd0
(hd1)   wd0
(hd2)   sd1

How do other people deal with this behaviour.

I guess I could remember to allways invoke grub(1) with --device-map
in order to not screw up the mbr and boot loaders on the non-boot disks
and actually have the boot loader installed on the correct disks.

If I could configure a kernel that would look for root on sd? and raid?,
that would help me, too.  But I can't do that.  config(8) refuses to handle
that.  And I can't undo the "config netbsd...." line like I can do "no device ..."

And lastly does any version of NetBSD probe the boot disk correctly?


--chris