>> si0 targ 5 lun 0: <IOMEGA, ZIP 100, N*32> SCSI2 0/direct removable
>> sd0 at scsibus0sd0(si0:5:0): illegal request, data = 00 00 00 00 24 00 00 00 00 00 ff fe 01 02 2d 00 00
>> sd0: could not mode sense (4); using fictitious geometry
>> : 96MB, 96 cyl, 64 head, 32 sec, 512 bytes/sec
>> root on sd10a
> That is because the dynamic assignment of sd* numbers does not match
> the fixed mapping the PROM passes to the kernel.

But, why is the kernel paying any attention to what the PROM thinks?
The PROM just passes in the boot device in the sd(0,28,0) form, right?
So the kernel knows the boot device is ID 5 LUN 0, so it should use
whichever disk is ID 5 LUN 0.  This seems relatively straightforward.
Or is doing this what thorpej is talking about when saying

> Chuck Cranor did this for the Sparc ... his scheme works with
> OpenPROM and Sunmon systems.  No doubt needs some munging for the
> sun3, but might be worth looking at for a model, at least.

It seems to me that the only MD part of this is getting the bootpath
and matching it against a potentially bootable device.  Seems to me
that either every device found should be checked with the MD code to
see if it's the boot device, or else after all device probing is done
the MD code should scan the list looking for the boot device.

Of course, that opinion is coming from someone who doesn't know the
relevant code and hence doesn't know how much redesign might be
required to implement those suggestions. :-)

gwr also sez

> You can work around that by booting with "-a" and specifying sd0 for
> everything.

Yeah, as I remarked in my note, that's exactly what I did.  It just
struck me as completely off-the-wall for the kernel to decide on sd10
when I couldn't see any justification for such a choice.  In
retrospect, I suspect the 10 was twice the SCSI ID (twice because in
the low IDs, there are two sd devices per ID in the Sun mappings).

					der Mouse

			    mouse@collatz.mcrcim.mcgill.edu