I just want to clarify, since I think you  may have missed my
question, even though you inadvertently answered it.

On Aug 13,  6:28pm, Greg Oster wrote:
} Subject: Re: RAIDFrame and NetBSD/sparc booting issues
} > Thiss would imply that disklabel -r sd0 or wd0
} > should read the label out of this protected region, assuming the raid
} > partition includes the entire disk.  Is this right?
} 
} No.  If the disklabel usually lives at block 0 for the arch, then the
} disklabel for raid0 will be found at block 0 of the data area of the RAID 
} set.  (i.e. typically at block RF_PROTECTEDSECTORS of the first component 
} of any RAID set).  Doing a 'disklabel sd0' or 'disklabel wd0' will 
} get the label from the underlying drive, but that will never contain 
} the disklabel for raid0 (at least as things currently stand).
	Actually, when I said sd0 or wd0, I was talking about the underlying
label for the physical disk, not the label which would reside on the
logical disk presented by the raid.  As such, if my understanding is
correct, this label should have a partition in it labeld as a "raid" partition,
which will start at some block number, and, RF_PROTECTEDSECTORS after that
block number, will be the beginning of the data area for the raid
component.  As you point out, it's a happy coincidence that the bootstrap
code and the physical disk labels fit inside the RF_PROTECTEDSECTORS region
of a raid partition which begins at block 0 of a disk.

	Now, here's another question.  When the autoconfigure code is
detecting raid components, I presume that it uses the physical disklabel to
find partitions of disks labeled as "raid" partitions.  Does it also use
the size of the partition listed in the physical label to determine the
offset and size of the raid partition, or does it use a private copy of the
size information for that raid partition in the component label which goes
inside that partition?  I would think that it would just use the
information inside the physical label, but sometimes, things don't work as
one might expect.

	Finally, since it seems my understanding of the layout of the disks
with raid partitions is correct, I maintain that it is easiest to achieve
transparency with respect to setting up bootable raid-1 partitions by
working with installboot, the second stage boot loaders, and sysinst to
layout disks which have their FFS filesystems begin at an offset compatible
with Raidframe's RF_PROTECTEDSECTORS constant.  I believe that, by default,
the superblock of an FFS filesystem begins 16 blocks after the beginning of
a partition so as to leave room for disklabels and bootstrap dcode.
Sysinst could be taught to form two partitions on systems which will have
raid installations:
1.  The "non-raie" partition, which would start at RF_PROTECTEDSECTORS
minus 16.

2.  The raid partition itself, which would begin, presumably, at the
beginning of the disk.  Then, if you told the ROM to boot from sd0a, the "A"
partition would lign up with your "raid" partition, and all would be well,
whether or not you were booting with a rooted raid partition, or just
booting the disk to run as a disk.

	I realize that this doesn't cover installations where folks didn't
realize they wanted a "raid" install from the outset, but do we really need
to cover that case?  
-Brian