gpart oddity

Marcel Moolenaar xcllnt at mac.com
Wed Oct 22 23:39:51 UTC 2008


On Oct 22, 2008, at 3:58 PM, Andriy Gapon wrote:

>> It's possible that I haven't merged all the changes from
>> HEAD to 7-stable. Try the following patch:
>> Index: g_part_bsd.c
>> ===================================================================
>> --- g_part_bsd.c    (revision 183454)
>> +++ g_part_bsd.c    (revision 183455)
>> @@ -293,7 +293,7 @@
>>     magic2 = le32dec(buf + 132);
>>     g_free(buf);
>>     return ((magic1 == DISKMAGIC && magic2 == DISKMAGIC)
>> -        ? G_PART_PROBE_PRI_NORM : ENXIO);
>> +        ? G_PART_PROBE_PRI_HIGH : ENXIO);
>> }
>> static int
>
> Yes, that was it, thank you again!

Cool... I'll make sure to sync 7-stable with HEAD soon...

> One hopefully last question: is disklabel supposed to keep working  
> in this new world or should I switch to gpart command exclusively?

disklabel(8) (and fdisk(8) for that matter) will not
work when you have partitions/slices mounted. So, in
that repsect, gpart will be only command that'll work
in all cases. If you don't have partitions mounted,
then disklabel(8) (and fdisk(8)) can be used to put
a label on the disk or modify a label that's already
there.

> $ disklabel ad4s1
> # /dev/ad4s1:
> 8 partitions:
> #        size   offset    fstype   [fsize bsize bps/cpg]
>  a:  2097152  2097215    4.2BSD        0     0     0
>  b:  2097152       63      swap
>  c: 587191752       63    unused        0     0         # "raw"  
> part, don't edit
>  d: 52428800  4194367    4.2BSD        0     0     0
>  e: 530568648 56623167    4.2BSD        0     0     0
> partition c: partition extends past end of unit
> disklabel: partition c doesn't start at 0!
> disklabel: An incorrect partition c may cause problems for standard  
> system utilities
> partition e: partition extends past end of unit
>
> It seems like offsets in disklabel output are now absolute (from  
> start of ad4), but previously they were relative to ad4s1 start:

Nah... This is one of the many kluges and quirks added
over time to patch up certain behaviour. disklabel(8)
uses a magic gctl request to ask the kernel at what
location (relative the the MBR) the label is on the
disk. This gctl is not supported by gpart because it
doesn't make sense and is broken. The disklabel(8)
utility should do exactly the same thing as the kernel
and use the offset of the 'c' partition to turn the
absolute offsets into relative offsets and not complain
about it.

In short: your label is absolute (and there's nothing
wrong with it) and disklabel(8) is broken :-)

-- 
Marcel Moolenaar
xcllnt at mac.com





More information about the freebsd-geom mailing list