Date: Wed, 22 Oct 2008 23:46:50 +0300 From: Andriy Gapon <avg@icyb.net.ua> To: Marcel Moolenaar <xcllnt@mac.com> Cc: Marcel Moolenaar <marcel@freebsd.org>, freebsd-geom@freebsd.org Subject: Re: gpart oddity Message-ID: <48FF913A.9070700@icyb.net.ua> In-Reply-To: <48FF82BA.3020309@icyb.net.ua> References: <48FF2607.10807@icyb.net.ua> <63F8346D-0116-4F41-BCAA-C235E9657BD8@mac.com> <48FF82BA.3020309@icyb.net.ua>
next in thread | previous in thread | raw e-mail | index | archive | help
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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?48FF913A.9070700>