NetBSD explodes FreeBSD disklabels if they're at the front of the disk.

[Thor Lancelot Simon <tls%panix.com@localhost>]

On Thu, Feb 03, 2011 at 01:14:37PM +0000, David Laight wrote:
> > 
> > But this is potentially very dangerous, in combination with
> > COMPAT_386BSD_MBRPART, because FreeBSD considers labels to be per-"slice"
> > (per fdisk-partition) and uses the 0x165 partition type.  So if we are not
> > very careful, we can hopelessly wreck FreeBSD installations in other
> > MBR partitions.
> 
> I'm not advocating (above) writing the NetBSD format label to a
> type 165 mbr partition.

Nonetheless, at least the code in NetBSD-5 is somehow doing exactly that.
I have two amd64 systems which must dual-boot NetBSD and FreeBSD for driver
porting.  I recently reinstalled them with FreeBSD 8.2-prerelease and
NetBSD, installing FreeBSD first and using the NetBSD bootselector to
switch back and forth.

When I tried to upgrade the FreeBSD systems to the head of the RELENG_8
branch, they wouldn't boot, because FreeBSD no longer trusts filesystem
parameters over label geometry.  That was when I booted the old FreeBSD
kernel and discovered that the NetBSD installer had scribbled all over
the FreeBSD disklabel.  This is unrecoverable under FreeBSD because FreeBSD
will not let you shrink a mounted partition, but FreeBSD install discs
don't have general-purpose tools for fixing this sort of thing.  Very ugly.

What happened, near as I can tell, is this:

1) I installed FreeBSD first and put it at the front of the disk.  Its
   type 165 partition's disklabel ended up at the absolute LABELSECTOR
   offset according to NetBSD.

2) I installed NetBSD into a second MBR partition of type 169.  However,
   it found the disklabel in MBR partition 1, of type 165, and scrawled
   the NetBSD disklabel all over it instead.

3) Shockingly, the system continued to boot FreeBSD, because FreeBSD
   until very recently trusted the filesystem geometry over the label
   geometry.

4) No more.  So NetBSD has stealthily poisoned my FreeBSD installation,
   and now, weeks later, it is dead.  Very sad.

Fdisk, disklabel (as the last FreeBSD kernel I can still run sees them)
follow:

# fdisk ad4
******* Working on device /dev/ad4 *******
parameters extracted from in-core disklabel are:
cylinders=155009 heads=16 sectors/track=63 (1008 blks/cyl)

Figures below won't work with BIOS for partitions not in cyl 1
parameters to be used for BIOS calculations are:
cylinders=155009 heads=16 sectors/track=63 (1008 blks/cyl)

Media sector size is 512
Warning: BIOS sector numbering starts with sector 1
Information from DOS bootblock is:
The data for partition 1 is:
sysid 165 (0xa5),(FreeBSD/NetBSD/386BSD)
    start 63, size 67108545 (32767 Meg), flag 80 (active)
        beg: cyl 0/ head 1/ sector 1;
        end: cyl 1023/ head 15/ sector 63
The data for partition 2 is:
sysid 169 (0xa9),(NetBSD)
    start 67108608, size 89141392 (43526 Meg), flag 0
        beg: cyl 1023/ head 0/ sector 1;
        end: cyl 1023/ head 14/ sector 46
The data for partition 3 is:
<UNUSED>
The data for partition 4 is:
<UNUSED>

# disklabel ad4s1
# /dev/ad4s1:
16 partitions:
#        size   offset    fstype   [fsize bsize bps/cpg]
  a: 80750880 67108608    4.2BSD     2048 16384     0 
  b:  8390512 147859488      swap                    
  c: 89141392 67108608    unused        0     0         # "raw" part, don't
edit
  d: 156250000        0    unused        0     0       
  e: 67108545       63    4.2BSD        0     0     0 
partition a: offset past end of unit
partition a: partition extends past end of unit
partition b: offset past end of unit
partition b: partition extends past end of unit
partition c: offset past end of unit
partition c: partition extends past end of unit
disklabel: partition c doesn't start at 0!
disklabel: partition c doesn't cover the whole unit!
disklabel: An incorrect partition c may cause problems for standard system
utilities
partition d: partition extends past end of unit
partition e: partition extends past end of unit