Subject: Re: Two NetBSDs on one (i386) drive
To: None <email@example.com>
From: David Laight <David.Laight@btinternet.com>
Date: 12/20/2001 15:46:54
> > | Try applying the rule: don't lie. At present, NetBSD lies to the user
> > | about DOS style partitioned disks.
> > What's the lie? NetBSD basically ignores DOS style partitioning
> > (other than as it is used by the BIOS for booting). As soon as a
> > NetBSD label is found, it gets used, and it is all that matters.
> > Is there something that suggests otherwise that should be fixed?
> For one, to access any of the other DOS style partitions you need to
> change the disklabel. NetBSD should be able to recognise the native
> partition table (on all platforms, actually) and provide some other,
> more convienient mechanism to access those partitions than through
> editting the disklabel.
It would seem to me (am I alone?) sensible for the stuff in the disklabel
to indicate how that part of the disk is structured. In particular with
the PC partition table it shouldn't really reference a 'DOS' partition.
With a system that can boot multiple OS, there is really some kind of
hierarchical space allocation. When NetBSD accesses a DOS filsystem
it is really accessing outside its own allocated space - so should be
using the 'native' scheme to find the bounds of the filesystem.
Can you multiboot a sparc system with solaris/netbsd (off the same disk)?
The standard solaris vtoc has so few partitions it must be quite hard...
What I have found today is that there are rather a lot of pieces of code
in netbsd that think they know how to find the disk label - and I haven't
looked at any kernel source yet!
The disklabel program will not write a disk label directly to a disk!
Even with '-r' (write directly to the disk) it tells the kernel about
the new layout.
It has also grovelled through mbr to find the (a) pbr.... but doesn't
completely ignore the sector identified by the device name.
(I had to restore the label using the install CD, I've not broken the
system with bad mbr bootcode)
I think the filesystem code will need looking at before it is possible
to ensure that netbsd always accesses the disk label that was used to
boot the system when doing normal operations.
Having multiple (separate) netbsd systems is getting trickier by the
To keep things terse, /dev/[r]wd0[ABCD] could be the main partitions,
You also need something for 'the whole disk'. The bigger problems
arise with minor device number mapping...
(I have a cunning thought about using an overlay of a disk directory
on top of a kernel pseudo file system for /dev. That way driver could
create the nodes for the devices that are present, using dynamic
(Soon to be away until the new year...)