Re: "geometry does not match label"

On Dec 30, 2008, at 9:11 AM, David O'Brien wrote:

> On Mon, Dec 29, 2008 at 10:31:47PM -0800, Marcel Moolenaar wrote:
>> On Dec 26, 2008, at 1:08 PM, Peter Jeremy wrote:
>>>> # disklabel /dev/ad8s4f
>>>> # /dev/ad8s4f:
>>>> 8 partitions:
>>>> #        size   offset    fstype   [fsize bsize bps/cpg]
>>>> c: 83441610 150994935    unused        0     0         # "raw"  
>>>> part,
>>>> don't edit
>>>> f: 83441610 150994935    4.2BSD        0     0     0
>>>> partition c: offset past end of unit
>>>> 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 f: offset past end of unit
>>>> partition f: partition extends past end of unit
>>>
>>> It looks like GEOM_PART_BSD reports partition information that is
>>> incompatible with bsdlabel.
>>
>> disklabel reads the label from the disk. It's wrong on the
>> disk.
>
> Given the number of existing disks that folks will use with
> GEOM_PART_BSD, can you whip up a utility to read the existing disk  
> label
> and write out a "proper" one?  (most preferably is a label that  
> releng7
> and releng6 kernels + utils will tolerate too).

I'll change bsdlabel to not ask GEOM_BSD what the MBR
offset is. Instead it'll make the label relative in the
same way the kernel does it. This fixes the "disklabel:
partition c doesn't start at 0!" and "disklabel: An
incorrect partition c may cause problems for standard
system utilities"

The "partition c: partition extends past end of unit"
can be fixed by the kernel in-memory so that you only
have to run "gpart commit /dev/ad8s4" to write it to
the disk. The kernel already does it, but doesn't yet
mark the in-memory label as dirty. You need to make
an unrelated change right now to cause the label to
be rewritten.

Unfortunately, there's no quick way to fix "partition
f: partition extends past end of unit" if it's really
larger than the slice size. If the warning is the
result of having an offset of !0, then it'll will be
fixed by fixing bsdlabel to make the label relative
on its own.

FYI,

-- 
Marcel Moolenaar
xcllnt_at_mac.com