NetBSD and OpenBSD label geoms.

[Loren M. Lang]

On Fri, Feb 11, 2005 at 11:44:56AM +0100, Poul-Henning Kamp wrote:
> In message <20050211102323.GA4287 at alzatex.com>, "Loren M. Lang" writes:
> >I have a quad-boot system with Gentoo Linux, FreeBSD, OpenBSD, and
> >NetBSD.  I was disappointed to see that none of the BSD's can see each
> >other.  (Linux could read at least 2 if not all of them.)  So, I'd like
> >to rectify that by making FreeBSD be able to read the NetBSD disklabel
> >and then OpenBSD's disklabel.  I'm thinking it will be easiest to copy
> >the FreeBSD disklabel geom and modify it to work with NetBSD, and then
> >merge it back into the FreeBSD disklabel code if it's still very
> >similar.
> 
> I belive all you need to do is to increase MAXPARTITIONS.

I tried to create a new geom for the netbsd disklabels where all I did
was change the partition id from 165 to 169 and renamed all the
functions from *bsd* to *nbsd* to avoid conflicts.  When I loaded the
new kernel module into freebsd, it still failed to taste properly so I
assume that there's some other fields that didn't add up correctly for a
freebsd disklabel.  I don't think that having MAXPARTITIONS would cause the
taste to fail like that from my understanding of it.

Also, why would netbsd change it's id from 165 to 169 if it was exactly the same?
Also I'm wondering why NetBSD would change it's id from 165 to 169.  Is
it just because of adding more partitions or to identify it as a
different OS?  I was suspecting that something more critical would be
different.

Also, there's the issue that the d partition is a special partition in
NetBSD that refers to the whole disk where the c partition is just the
whole disklabel.  In freebsd the c partition serves the same purpose,
but for the whole disk you have to access it by other means and by-pass
the disklabel.  I think this is do to NetBSD deciding to make all the
offsets relative to start of disk where FreeBSD has all offsets relative
to start of slice containing disklabel, but I could be wrong on this.
Though based off of my understanding of GEOM, the freebsd disklabel geom
wouldn't even realize how big the real drive is, and it would have to be
designed relative to the start of slice which is the provider that it's
attached to.

> 
> -- 
> Poul-Henning Kamp       | UNIX since Zilog Zeus 3.20
> phk at FreeBSD.ORG         | TCP/IP since RFC 956
> FreeBSD committer       | BSD since 4.3-tahoe    
> Never attribute to malice what can adequately be explained by incompetence.

-- 
I sense much NT in you.
NT leads to Bluescreen.
Bluescreen leads to downtime.
Downtime leads to suffering.
NT is the path to the darkside.
Powerful Unix is.

Public Key: ftp://ftp.tallye.com/pub/lorenl_pubkey.asc
Fingerprint: B3B9 D669 69C9 09EC 1BCD  835A FAF3 7A46 E4A3 280C