DragonFlyBSD

I think it's because the in-kernel disklabel (without -r) is not allowed
to upgrade a FreeBSD disklabel to a DragonFly disklabel. I haven't look
at the code carefully but its likely I am doing a sanity check to
prevent that case somewhere where both DIOCGDINFO and DIOCSDINFO call.
It's a bug for the GDINFO case. The reason we don't allow an upgrade
is because the FreeBSD disklabel does not have room for 16 partitions,
because FreeBSD moved the boot code to be right after the disklabel
in order to make room for both UFS1 and UFS2 recognition.

With -r the disklabel program looks at the disk directly and is able
    to discern the difference between a DragonFly disklabel (with support
    for 16 partitions), and a FreeBSD disklabel.

-Matt
                    Matthew Dillon 
                    <dillon@backplane.com>

:Perhaps a little background first:
:
:I've been using both DragonFly-current and FreeBSD-current from
:extended(logical) slices for about a year or so. This is possible
:only because the DragonFly /boot/loader was patched to parse the
:DOS partition table correctly (unlike the FBSD version).
:
:Now -- can any of you gurus explain why the DragonFly disklabel
:program behaves this way when reading a FreeBSD disklabel:
:
:# disklabel ad1s8 [this is FBSD on an extended/logical slice]
:disklabel: ioctl DIOCGDINFO: Invalid argument
:
:BUT, if I add the -r flag, it works normally:
:
:# disklabel -r ad1s8
:# /dev/ad1s8c:
:type: unknown
:disk: amnesiac
:label:
:flags:
:bytes/sector: 512
:sectors/track: 63
:tracks/cylinder: 16
:sectors/cylinder: 1008
:cylinders: 16654
:sectors/unit: 16787862
:rpm: 3600
:interleave: 1
:trackskew: 0
:cylinderskew: 0
:headswitch: 0 # milliseconds
:track-to-track seek: 0 # milliseconds
:drivedata: 0
:
:8 partitions:
:# size offset fstype [fsize bsize bps/cpg]
: a: 16273746 514080 4.2BSD 2048 16384 25600 # (Cyl. 510 - 16654*)
: b: 514080 0 swap # (Cyl. 0 - 509)
: c: 16787862 0 unused 0 0 # (Cyl. 0 - 16654*)
:super block size 0
:
:Is this a bug in 'disklabel'? Or not.
:
:Thanks for any clues!

Matthew Dillon wrote:

...The reason we don't allow an upgrade
is because the FreeBSD disklabel does not have room for 16 partitions,
because FreeBSD moved the boot code to be right after the disklabel
in order to make room for both UFS1 and UFS2 recognition.

With -r the disklabel program looks at the disk directly and is able
to discern the difference between a DragonFly disklabel (with support
for 16 partitions), and a FreeBSD disklabel.

You may recall that I posted a related question recently, the reason
being that GRUB was suddenly confused by that same FBSD bootlabel.

Just FYI: I edited the FBSD disklabel (while running DragonFly):
'disklabel -r -e ad1s8'
and made a trivial change (I changed 'amnesiac' to 'FreeBSD') and
suddenly GRUB is happy again! I can also mount that extended
partition from either FBSD or DF.

This suggests to me that the DF 'disklabel' is somehow more 'correct'
than the FBSD version -- but I don't know just how or why...

Thanks!

On Mon, 16 Jan 2006, Matthew Dillon wrote:

[...]

With -r the disklabel program looks at the disk directly...

Further developments have me completely mystified and I'm suspecting
than only black magic can be responsible ;o)

I've used 'dd' extensively while trying to solve my disklabel puzzle.

I just discovered that DragonFly's 'dd', when reading a disklabel
sector, gives a different result than the 'dd' from FBSD, linux, and
a raw-disk editor I use on Windows:

1. dd if=/dev/ad1s11 iseek=1 count=1 | hd
   1+0 records in
   1+0 records out
   00000000 57 45 56 82 00 00 00 00 44 46 00 00 00 00 00 00 |WEV.....DF......|
   00000010 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 |................|
   00000020 00 00 00 00 00 00 00 00 00 02 00 00 3f 00 00 00 |............?...|
   00000030 10 00 00 00 b7 28 00 00 f0 03 00 00 cf 50 a0 00 |.....(.......P..|
   00000040 00 00 00 00 00 00 00 00 10 0e 01 00 00 00 00 00 |................|
   00000050 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 |................| *
   00000080 00 00 00 00 57 45 56 82 5d 31 08 00 00 20 00 00 |....WEV.]1... ..|
   00000090 00 20 00 00 0e 12 a0 00 00 00 00 00 00 00 00 00 |. ..............|
   000000a0 07 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 |................|
   000000b0 00 00 00 00 0e 12 a0 00 00 00 00 00 00 00 00 00 |................|
   000000c0 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 |................| *
   512 bytes transferred in 0.008378 secs (61114 bytes/sec)

I direct your attention to bytes 908-911, and b08-b11. These are
the bytes corresponding to 'p_offset' for partitions 'a' and 'c'
in the disklabel as defined in disklabel.h:

struct  partition {             /* the partition table /
                u_int32_t p_size;       / number of sectors in partition /
                u_int32_t p_offset;     / starting sector */

Now, my problem is that FBSD, linux, and Windows all agree that
those two 'offset' fields are wrong, and are not zeros but
c0 73 02 09. This is the correct value for the absolute number
of sectors from the start of the physical disk to the start of
ad1s11.

I can only conclude that DragonFly's 'dd' is looking at that disk
sector through eyes that know the difference between a disklabel
sector and any other sector. This seems hard to believe, but I
dunno.

Any thoughts on why DF disagrees with the other three OS's?

Thanks!

:I've used 'dd' extensively while trying to solve my disklabel puzzle.
:
:I just discovered that DragonFly's 'dd', when reading a disklabel
:sector, gives a different result than the 'dd' from FBSD, linux, and
:a raw-disk editor I use on Windows:
:
:# dd if=/dev/ad1s11 iseek=1 count=1 | hd
:1+0 records in
:1+0 records out
:00000000 57 45 56 82 00 00 00 00 44 46 00 00 00 00 00 00 |WEV.....DF......|
:00000010 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 |................|
:00000020 00 00 00 00 00 00 00 00 00 02 00 00 3f 00 00 00 |............?...|
:00000030 10 00 00 00 b7 28 00 00 f0 03 00 00 cf 50 a0 00 |.....(.......P..|
:00000040 00 00 00 00 00 00 00 00 10 0e 01 00 00 00 00 00 |................|
:00000050 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 |................|
:*
:00000080 00 00 00 00 57 45 56 82 5d 31 08 00 00 20 00 00 |....WEV.]1... ..|
:00000090 00 20 00 00 0e 12 a0 00 00 00 00 00 00 00 00 00 |. ..............|
:000000a0 07 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 |................|
:000000b0 00 00 00 00 0e 12 a0 00 00 00 00 00 00 00 00 00 |................|
:000000c0 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 |................|
:*
:512 bytes transferred in 0.008378 secs (61114 bytes/sec)
:
:
:I direct your attention to bytes 908-911, and b08-b11. These are
:the bytes corresponding to 'p_offset' for partitions 'a' and 'c'
:in the disklabel as defined in disklabel.h:
:
: struct partition { /* the partition table /
: u_int32_t p_size; / number of sectors in partition /
: u_int32_t p_offset; / starting sector /
:
:Now, my problem is that FBSD, linux, and Windows all agree that
:those two 'offset' fields are *wrong, and are not zeros but
:c0 73 02 09. This is the correct value for the absolute number
:of sectors from the start of the physical disk to the start of
:ad1s11.

The disklabel is relative to a slice (ad1s11), NOT the base of
    the raw disk.  The slice has no concept of the rest of the disk.
    This is true of FreeBSD as well.  I have no idea why the numbers
    you are getting would be different.

:I can only conclude that DragonFly's 'dd' is looking at that disk
:sector through eyes that know the difference between a disklabel
:sector and any other sector. This seems hard to believe, but I
:dunno.
:
:Any thoughts on why DF disagrees with the other three OS's?
:
:Thanks!

-Matt
                    Matthew Dillon 
                    <dillon@backplane.com>