grub/Xen2 and having SCSI and SATA disks

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

On Wed, Jun 13, 2007 at 05:35:05PM +0200, Christoph Badura
wrote:
> 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.

NetBSD doesn't get bootinfo from grub. This is what the
bootdev=
boot line option is for (in your case you probably want
bootdev=ld0)

> 
> 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.)

works for me ...

-- 
Manuel Bouyer <bouyerantioche.eu.org>
     NetBSD: 26 ans d'experience feront toujours la
difference
--

On Wed, Jun 13, 2007 at 10:40:28PM +0200, Manuel Bouyer
wrote:
> On Wed, Jun 13, 2007 at 05:35:05PM +0200, Christoph
Badura wrote:
> NetBSD doesn't get bootinfo from grub. This is what the
bootdev=
> boot line option is for (in your case you probably want
bootdev=ld0)

No, obviously it doesn't.  That begs the question what all
the code
is supposed to do that relies on Xen getting the bootinfo
from the
bios?

> > (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.)
> works for me ...

What works for your?

--chris

On Thu, Jun 14, 2007 at 06:05:57PM +0200, Christoph Badura
wrote:
> On Wed, Jun 13, 2007 at 10:40:28PM +0200, Manuel Bouyer
wrote:
> > On Wed, Jun 13, 2007 at 05:35:05PM +0200,
Christoph Badura wrote:
> > NetBSD doesn't get bootinfo from grub. This is
what the bootdev=
> > boot line option is for (in your case you probably
want bootdev=ld0)
> 
> No, obviously it doesn't.  That begs the question what
all the code
> is supposed to do that relies on Xen getting the
bootinfo from the
> bios?

I suspect it's an heritage from i386. What code are you
talking about ?

> 
> > > (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.)
> > works for me ...
> 
> What works for your?

It properly probes ld(4)

-- 
Manuel Bouyer <bouyerantioche.eu.org>
     NetBSD: 26 ans d'experience feront toujours la
difference
--

On Thu, Jun 14, 2007 at 08:17:29PM +0200, Manuel Bouyer
wrote:
> On Thu, Jun 14, 2007 at 06:05:57PM +0200, Christoph
Badura wrote:
> > No, obviously it doesn't.  That begs the question
what all the code
> > is supposed to do that relies on Xen getting the
bootinfo from the
> > bios?
> I suspect it's an heritage from i386. What code are you
talking about ?

The code in matchbiosdisks(), findroot(), cpu_rootconf() in
sys/arch/xen/i386/autoconf.c for example.

> > > > 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.)
> > > works for me ...
> > What works for your?
> It properly probes ld(4)

So, you invoke just plain "grub --no-floppy" and
it probes the ld(4) disks
that the kernel knows about?  I don't believe you.  Because
there is no
code in lib/device.c that opens an ld(4) device.

--chris

On Fri, 15 Jun 2007 07:11:10 am Christoph Badura wrote:
> > > > > 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.)
> > > >
> > > > works for me ...
> > >
> > > What works for your?
> >
> > It properly probes ld(4)
>
> So, you invoke just plain "grub --no-floppy"
and it probes the ld(4) disks
> that the kernel knows about?  I don't believe you.
 Because there is no
> code in lib/device.c that opens an ld(4) device.

I believe he was referring to the bootdev parameter working.
I require the 
bootdev parameter to avoid the detection/use of the
occasional USB drive 
being left inserted prior to boot.

There is definitely a preferred order (or lack of
preference) and the bootdev 
parameter prevents this being an issue.

Sarton

On Thu, Jun 14, 2007 at 11:11:10PM +0200, Christoph Badura
wrote:
> On Thu, Jun 14, 2007 at 08:17:29PM +0200, Manuel Bouyer
wrote:
> > On Thu, Jun 14, 2007 at 06:05:57PM +0200,
Christoph Badura wrote:
> > > No, obviously it doesn't.  That begs the
question what all the code
> > > is supposed to do that relies on Xen getting
the bootinfo from the
> > > bios?
> > I suspect it's an heritage from i386. What code
are you talking about ?
> 
> The code in matchbiosdisks(), findroot(),
cpu_rootconf() in
> sys/arch/xen/i386/autoconf.c for example.

I think it's mostly unused or useless. I think the only
important thing is
the call to xen_parse_cmdline(XEN_PARSE_BOOTDEV, &xcp)
in findroot().
This needs cleanup, but whenever it's possible to get some
information from
grub via Xen needs to be investicated. 

> 
> > > > > 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.)
> > > > works for me ...
> > > What works for your?
> > It properly probes ld(4)
> 
> So, you invoke just plain "grub --no-floppy"
and it probes the ld(4) disks
> that the kernel knows about?  I don't believe you. 
Because there is no
> code in lib/device.c that opens an ld(4) device.

Hum, maybe I added the ld entry myself in device.map, I
can't remember.
But booting a ld device from grub definitively works 

-- 
Manuel Bouyer, LIP6, Universite Paris VI.          
Manuel.Bouyerlip6.fr
     NetBSD: 26 ans d'experience feront toujours la
difference
--

On Fri, Jun 15, 2007 at 11:19:54AM +0200, Manuel Bouyer
wrote:
> Hum, maybe I added the ld entry myself in device.map, I
can't remember.
> But booting a ld device from grub definitively works


That would work, of course.  The grub loader makes only BIOS
calls and the
RAID controller's BIOS extension would handle it.

--chris