On Thu, 11 Nov 2004 06:38:44 -0500
Tim Kelly <hockey@dialectronics.com> wrote:

> 
> 2) I figured out that the problem with the kernel misidentifying the
> boot device appears to be in the manner in which the boot path is
> specified in Open Firmware. For example,
> 
> boot scsi-int/@6:0,\ofwboot.xcf netbsd
> 
> is a perfectly valid path, even though I didn't specify "sd." This is
> because OF will use the first child of scsi-int it finds, and sd will
> always be found before st. However, once this has been through the
> canonization routine in autoconf.c, the node has been dropped and the
> canonized bootpath becomes (stuff)/sd@0. I hope to have a patch on
> this soon.

I'm looking for (offline) testers for a patch I wrote for this. I've
tested it against OF 1.0.5 and it fixed two problems. 

One is the problem above, so that both of

boot scsi-int/sd@6:0,\ofwboot netbsd

boot scsi-int/@6:0,\ofwboot netbsd

are valid. If you need to boot from a child other than the first one,
then specify that child (in the case above, "st" is the second child,
which we don't want because we want the first child, sd). However, I
strongly recommend the use of Open Firmware's aliases to do a lot of the
thinking for you.

The other problem is that if two hard drives are valid NetBSD installs,
and the higher target ID is booted from, the lower target ID is the file
system used by the kernel. I can now boot from sd@6 with sd@0 hooked up.

I'd like to get a wider range of testing, if possible, even if you've
only got one hard drive, and especially if you've got an OF 3.0 box.

thanks,
tim