DragonFly bugs List (threaded) for 2006-01
Re: Disklabel question (versus bug)
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.
: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
:headswitch: 0 # milliseconds
:track-to-track seek: 0 # milliseconds
:# 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!