Subject: Re: disklabel(8) and machdep on-disk structures issues
To: Luke Mewburn <>
From: Bill Studenmund <>
List: tech-kern
Date: 11/11/2003 11:35:19
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable

On Mon, Nov 10, 2003 at 11:02:01AM +1100, Luke Mewburn wrote:
> On Sun, Nov 09, 2003 at 07:37:53PM +0100, Hauke Fath wrote:
>   | Sure, but you definitely do not want to blow away an Apple partition =
>   | and replace it with a NetBSD disklabel, even if the disklabel gets the
>   | partitions right.
> Does the raw label share the same location on the disk as the
> "native platform" label?  If so, that's a design flaw in that

Luke, you're assuming the two can coexist. Apple partition maps take up=20
enough space in each block that we can't fit a NetBSD disklabel in=20

I think a better way to refine the desire of this thread is that if the=20
kernel believes that writing a disklabel won't stomp on something, it=20
should write the disklabel. Thus if the kernel knows there's a=20
non-DISKLABEL partition map, it should _not_ write a disklabel, unless of=
course there's a place in said map for the DISKLABEL partition map.

crap on disk		->	write DISKLABEL
NetBSD disklabel	->	write DISKLABEL
mbr w/ NetBSD partition
    but no DISKLABEL	->	write DISKLABEL
mbr w/o NetBSD parition ->	Don't write
Apple partition map (**)->	Don't write

(*) Technically the disklabel overwrites "driver identifiers" in block 0.=
For NetBSD-only disks, we can get away w/o having them. For MacOS-enabled=
disks (well older ones), we can't write over them. So sometimes it's safe,=
sometimes not.

(**) The macppc kernel looks for NetBSD disklabels before Apple partition=
maps, so if it "found" an Apple partition map, there isn't a NetBSD one.

Take care,


Content-Type: application/pgp-signature
Content-Disposition: inline

Version: GnuPG v1.2.3 (NetBSD)