gpart oddity

Andriy Gapon avg at icyb.net.ua
Wed Oct 22 20:46:56 UTC 2008


on 22/10/2008 22:44 Andriy Gapon said the following:
> on 22/10/2008 20:28 Marcel Moolenaar said the following:
>> This is a problem with your configuration. You have not disabled
>> GEOM_BSD (nor GEOM_MBR) by adding "nooption GEOM_BSD" (and
>> "nooption GEOM_MBR"). For now it's best to keep it, because the
>> old BSD slicer does not check your disklabel and accepts it.
> 
> Yes, this is exactly what happened.
> I was about to reboot to a kernel built with those nooptions when I got 
> your email - thanks a lot for saving me from being puzzled!
> 
>> Can you send me the output of dd for ad4s1, like:
>>
>>     dd if=/dev/ad0s1 of=/tmp/dump count=16
>>
>> As well as the output of sysctl kern.geom.conftxt.
>>
>> That allows me see in what way your BSD disklabel is invalid.


Being impatient I actually glimpsed through the code and gathered some 
more data and I think that the issue is in incorrect value of 
d_secperunit (offset 60).

Compare:
$ disklabel -A ad4s1
# /dev/ad4s1:
type: ESDI
disk: ad4s1
label:
flags:
bytes/sector: 512
sectors/track: 63
tracks/cylinder: 16
sectors/cylinder: 1008
cylinders: 620181
sectors/unit: 625142448
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:  2097152  2097152    4.2BSD        0     0     0
   b:  2097152        0      swap
   c: 587191752        0    unused        0     0         # "raw" part, 
don't edit
   d: 52428800  4194304    4.2BSD        0     0     0
   e: 530568648 56623104    4.2BSD        0     0     0
disklabel: partition c doesn't cover the whole unit!
disklabel: An incorrect partition c may cause problems for standard 
system utilities

$ fdisk ad4
******* Working on device /dev/ad4 *******
parameters extracted from in-core disklabel are:
cylinders=620181 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=620181 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 587191752 (286714 Meg), flag 80 (active)
         beg: cyl 0/ head 1/ sector 1;
         end: cyl 1023/ head 8/ sector 63
The data for partition 2 is:
sysid 165 (0xa5),(FreeBSD/NetBSD/386BSD)
     start 587191815, size 37945530 (18528 Meg), flag 80 (active)
         beg: cyl 1023/ head 255/ sector 63;
         end: cyl 1023/ head 14/ sector 63
The data for partition 3 is:
<UNUSED>
The data for partition 4 is:

'cylinders' value reported for ad4s1 is the same as 'cylinders' reported 
for the whole ad4.
This is definitely incorrect.

ad4s2 disklabel contains reasonable/correct values on the other hand.

Then I remembered that I labeled ad4s1 purely through sysinstall and 
never touched it with disklabel(8), on the other hand I used disklabel 
to label ad4s2.

Then I did 'disklabel -e ad4s1' and saved the label without changing 
anything. After that:
$ disklabel -A ad4s1
# /dev/ad4s1:
type: unknown
disk: amnesiac
label:
flags:
bytes/sector: 512
sectors/track: 63
tracks/cylinder: 16
sectors/cylinder: 1008
cylinders: 582531
sectors/unit: 587191752
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:  2097152  2097152    4.2BSD        0     0     0
   b:  2097152        0      swap
   c: 587191752        0    unused        0     0         # "raw" part, 
don't edit
   d: 52428800  4194304    4.2BSD        0     0     0
   e: 530568648 56623104    4.2BSD        0     0     0

Now 'cylinders' and 'sectors/unit' have correct values.

My personal conclusions:
1. sysinstall seems to have handled those fields incorrectly, somehow.
2. those fields do not seem to be of any particular use/importance, so 
g_part_bsd might be overly strict here.

Anyway, I am glad this was that simple.
Thank you very much for your help!

I'll try to boot into a new kernel now (the one without GEOM_MBR and 
GEOM_BSD).

-- 
Andriy Gapon


More information about the freebsd-geom mailing list