Date:        Mon, 16 Jun 2003 13:05:18 +0100
    From:        David Laight <david@l8s.co.uk>
    Message-ID:  <20030616130518.L3322@snowdrop.l8s.co.uk>

  | Let's put it another way, to do anything else would require the disklabel
  | editing code to know all the mbr rules.

That's why I suggested in the earlier message that the whole thing
should be done together.   So, yes, that's exactly what it should do.

  | This is (just) plausible if you
  | are going make each filesystem a separate (extended) mbr partition, but
  | otherwise it is just too hard.

This makes no sense to me at all - if you're able to make one filesystem
in an extended MBR partition, it is beyond trivial to take that
filesystem, divide it into N separate disklabel partitions, and N
filesystems, and leave all else alone.   I am not suggesting that
it should be possible (easily in sysinst anyway) to take a NetBSD
filesystem and split it amongst MBR partitions, there's no reason
to even want that.

Alternatively, you can take filesystems, and then work out how to
place those into MBR partitions that meet the rules (in most cases,
where the user hasn't given explicit "start at block N" instructions,
you can move the filesystems around a little to meet constraints).

  | But the disk layout has to be consistent with the machine architecture.
  | On i386 that means the disks have an mbr that describes where the
  | filesystems are on the disk....

No, it doesn't.  On i386 all the MBR does is allow the bios to find
boot information.   There's nothing else about the architecture that
cares at all.   Linux (even FreeBSD) make more assumptions.   I haven't
looked at this with recent wintrash systems, but even they used to ignore
much of the MBR - that is, they'd use it to find where filesystems might
start, but they certainly didn't care about filesystems straying outside
MBR boundaries (the format command looked to see how big it should make
the filesystem - from the MBR, but once built, changing the size in the
MBR has zero effect on anything).

All the i386 really requires is that it can find the boot code - beyond
that, everything is up to how the booted OS wants to treat things.

The only reason for NetBSD to have anything to do with the MBR at all
(other than what is needed to boot, and find the NetBSD label) is for
compatability with other systems (dual booting).   We need only the
minimum necessary to allow that to work (which is, really, that all
the space that NetBSD is using is marked as used).   Anyone else
who wants to access NetBSD filesystems needs to do it the same way
NetBSD does - find the NetBSD label, and use that to locate the filesystems.

  | (This is, in some sense, not dissimilar to what happens on sun systems,
  | where netbsd uses the sun disklabel format.)

Not really, sun proms understand the filesystem layout inside those
filesystems, not just the positioning.   And NetBSD just makes a Sun
format copy of its label for the benefit of the proms - most Sun
NetBSD users probably don't even realise that there are separate
labels, one for the prom, and one for NetBSD.   That's the way it
should be (I mean, that the users don't realise).

  | I make it 9 of 32 (known to sysinst).  However I suspect it is most of
  | the installations.

Of course, as the vast majority of the installations are i386.
But that's something that NetBSD has always consciously set out not
to allow to influence the system design.

kre

ps: I'd still like the possibility of multiple different NetBSD labels
on one drive, selecting which to use at boot time (use the one in
the partition that was booted from), but that's orthogonal to all the
above, and not something I'd expect sysinst to be able to construct.