I'm going to reply to all the messages on this in one message:

rb-netbsd@BigScaryChildren.net (Rick Byers) said:
| If we recognize more than one NetBSD partition on a disk, that means
| more than one disklabel.

Yes, that's more or less the aim.

| Wouldn't that cause a bunch of problems?

Some perhaps - but none that you have to endure, no-one is going to
make anyone use any of this.

| For example, how do I write the second disklabel when I've booted from
| the first partition? 

disklabel /dev/r[ws]d0g (or something) I assume.   Where wd0g is the same
partition as wd0a will be in the other boot.

Or just not at all - there's no need that the two NetBSDs be able to
see each other at all, if that's preferred - I can boot and install one
of them from floppy, and then boot and install the 2nd one the same way
ideally - just using a different partition on the drive (sysinst would need
to learn about that, and it isn't a priority, but it is certainly possible).

| I would find it confusing because now there are two different NetBSD
| views of the disk

Then you wouldn't use it.   I would...

| (i.e. the meaning of "wd0a" depends on which partition you booted from

Yes, that's an aim.

| what if you boot from a floppy?

That's a good question - there would probably need to be a way to tell
the kernel which it should use in the askname case.   But even if it
simply picked the first NetBSD it finds (like now), that would do - we
wouldn't be losing anything, just not gaining as much as would otherwise
be possible.

| Wouldn't it be better to just have one NetBSD partition and create
| seperate disklabel slices for the two systems?

No.   This has been suggested several times, I will reply to one of the
others.

| Multiple NetBSD installations on one disk is something that should be
| possible on any platform, and so shouldn't need a platform specific
| solution.

Yes, that would be better - but most other systems don't have this
extra level of labels on their drives - which makes the whole thing
more difficult.   On the other hand, most other systems have boot
methods that actually things to work better without needing this kind
of extra support - the x86 boot system's limitations are what causes
the problems (ie: all I can tell an x86 system is which partition to
boot from - on the other hand I can tell a Sun to boot from sd0e or something
if I want to).   I mean here "configure the box so it auto boots as ..."
not "manually boot by interrupting the boot sequence" which isn't adequate.

martin@duskware.de said:
| You can hardwire different root partitions into the different kernels

Yes, I know - that is exactly what I don't want to have to do.   I want to
be able to build a test system, test it, and then use it in production,
without changing it at all (as soon as it is changed, it has to be tested
again before being used).   So, compiled in root locations are not an option.

gillham@vaultron.com said:
| Seems like you could just build 1.5.x to only recognize partition type
| 165 (MBR_COMPAT or whatever), and build -current to only recognize
| type 169 and you would be set.

Yes, I know, that was the unclean solution I mentioned.   Again, that probably
means recompiling when moving the test system to the real place - though this
way it could be avoided by swapping around the "slice" partition types
(use 165 in production, test using 169, when the test system is good, copy
it to the production area, and swap the two types - now using 169 in
production and 165 for testing for the next time) so it isn't as impossible
as the "compile in the root partition" scheme.   But it is just plain ugly.

gillham@vaultron.com said:
| Better to pass in the MBR partition number and have the boot code and
| kernel honor it when looking for the "NetBSD" partition.

That is what I thought.

darrenr@reed.wattle.id.au said:
| This is a symptom of other problems in how we address DOS disk
| partitions under NetBSD.  At some point we need to start using slices
| so we can have wd0s[1-4][a-?].

The "confusion" that Rick Byers mentioned (which is what was being replied
to here) could be avoided that way - if there's actually a need to avoid it
at all.

I keep looking at that, and deciding I like it, then a bit later keep on
coming back to the NetBSD way as better.

The "name the slice" model uses the basic premise that the slices model
different drives (same as c: d: ...).   That has some attraction, but makes
it real hard to then sensibly have the label on a slice refer to a part of
a different slice.   That can be a useful thing to do sometimes - it isn't
needed when the other slice can have a NetBSD compatible label in it (eg: if
it is another NetBSD or if it is FreeBSD, etc), but if the slice doesn't have
any kind of *BSD compatible label, then referring to a part of it would become
real hard (while retaining purity anyway).

So, I usually reach the conclusion that the NetBSD way - "there is just one
label on this drive that we use, and it refers to the whole physical drive"
is actually cleaner - and now that there are enough slots in the label to
name everything that needs naming, it is no longer a limitation (when there
were only 6 usable slots, wanting to access another label was very tempting,
now there are 14 it no longer is).

What I'd like to be able to do is just to have more than one NetBSD label
on the drive, and select the one to use based upon where I booted from.

David.Laight@btinternet.com said:
| OK, so how do I tell the bootloader to pull in a different filesystem,
| and how does the kernel find its root filesystem.

You can compile the kernel to know that its root should be on sd2g if you
want to (or anything else that exists).

David.Laight@btinternet.com said:
| Anyway I now have another mbr_bootsel code that will pass the start
| sector through to the next level.

That sounds good, great in fact.

| (editing that code makes my brain explode - and I haven't trashed a
| boot block yet) 

Now you see why I (who has never written a line of *386 specific code
in my life) sent the "I would like" message rather than just writing
the code myself ...    I did go look at some of that, and while I could
follow it enough to be able to guess what was happening, no way could
I safely modify it (and certainly not improve it along the way).

We still really need to find out how other systems do this though, that
is...

vance@aurema.com said:
| FreeBSD allows this now, changing quite some time ago from wd<n>[a-h]
| to wd<n>s<m>[a-h] (and then to ad<n>s<m>[a-h]).  It's quite possible
| to distinguish ad0s2a from ad0s4a.

The naming scheme is one issue - how the boot code (starting from the mbr)
tells the later boot code exactly where it came from is another.   If FreeBSD
has a way to send this from their boot code, up to their kernel, so the
kernel knows (without having to have information compiled into it) which
slice it came from, so the 'a' on that slice can be root, then I would suggest
that NetBSD should copy the method - so either one's boot loader can be
used to boot the other's kernel (with full functionality).

vance@aurema.com said:
| You can still boot a kernel directly from earlier boot stages instead
| of going through /boot/loader, but I'm not sure whether you lose the
| ability to choose slices.  

If on the other hand, the FreeBSD method is something like LILO, which has
a config file it reads, to tell it what to do (and so, what the mbr boot
code does is almost irrelevant) then I am much less interested.  If that's
the only way to boot from other than the first slice, then I think NetBSD can
do much better.

soda@sra.co.jp said:
| I have three distinct NetBSD installations (1.2.1, 1.3.3, 1.5ish) on
| one i386 drive by using /dev/wd0a, /dev/wd0e and /dev/wd0f as each
| root partition. Isn't this way distinct enough for your purpose?

I assume you have those kernels compiled to have root on wd0a (or just
on ? for that one) wd0e and wd0f respectively.   That's exactly what I
don't want to do.   For running older systems like that, to get the
ability to test things on a much older system, that would be a good
enough solution (probably better than what I'm suggesting, as you can
easily have many more than 4 systems set up).

But what I want is yesterday's working -current on one slice, and today's
with the latest hack (mine or someone else's) on another, test the new one,
then if it works, simply copy it to replace the current system (just the
kernel in many cases, the entire root & /usr in others).

I'd also like it to be as difficult as possible (given all of this is on
one drive) for the test system to interfere with the real one - even with
my connivance...   That is, while the real system would have a label with
partitions on it for the test system's filesystems, so they could all be
mounted, the label for the test system wouldn't be able to see the real
system's partitions at all, it would be isolated.   Of course, I could
edit the label and then mount a production fileystem, but that's taking
real effort, and so I would be less tempted,  so just leaving the entries
out of the test system's /etc/fstab is less attractive (if I know that
wd0h is where my home directory lives, and I decide I need something,
it would be very tempting to "mount /dev/wd0h /home" - and by so doing
risk my test system wrecking that filesystem).

Sorry for the very long message - it seemed simpler than sending 7 messages
in a row.

kre