Re: "geometry does not match label"

On 2008-Dec-26 00:54:53 -0800, David O'Brien <obrien_at_freebsd.org> wrote:
># fsck /dev/ad8s4f
>fsck: Could not determine filesystem type

I'm seeing this as well but it seems to go away if the filesystem is listed
in /etc/fstab.

># 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.  This is a PITA.  OTOH, 'gpart show'
works sanely (though you have to map from 1-origin partition numbers
to partition names).

If GEOM_PART_xxx is going to be kept as the default, either bsdlabel
needs to learn how to interpret the partition information (preferred)
or it needs to refer the user to gpart(8) and not produce confusing
and erroneous error messages.

Overall, gpart is definitely not a user-friendly way of managing disk
space (though it is usable).  As has already been noted (in part):
1) it needs to use expand_number(3) or similar to read sizes
2) the '-b offset' option to 'gpart add' needs to be made optional
3) the '-i index' option to 'delete', 'modify', 'set' and 'unset' needs
   to be optional (derived from the 'geom' argument if not specified -
   so 'gpart delete -i 3 ad4' and 'gpart delete ad4s3' are equivalent).

-- 
Peter Jeremy
Please excuse any delays as the result of my ISP's inability to implement
an MTA that is either RFC2821-compliant or matches their claimed behaviour.