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