"geometry does not match label"
Christian Weisgerber
remember seeing before:
GEOM: ad6s1: geometry does not match label.
bsdlabel offers suitably scary warnings:
$ bsdlabel ad6s1
# /dev/ad6s1:
8 partitions:
# size offset fstype [fsize bsize bps/cpg]
a: 2097152 63 4.2BSD 2048 16384 28528
b: 8396800 2097215 swap
c: 293041602 63 unused 0 0 # "raw" part, don't edit
d: 20971520 10494015 4.2BSD 2048 16384 28528
e: 2097152 31465535 4.2BSD 2048 16384 28528
f: 62914560 33562687 4.2BSD 2048 16384 28528
g: 62914560 96477247 4.2BSD 2048 16384 28528
h: 133649858 159391807 4.2BSD 2048 16384 28528
partition c: partition extends past end of unit
bsdlabel: partition c doesn't start at 0!
bsdlabel: An incorrect partition c may cause problems for standard system utilities
partition h: partition extends past end of unit
I don't know where this is coming from--the system was installed
about a year ago with standard sysinstall--and I don't see what's
supposed to be wrong.
$ gpart show
=> 63 293046705 ad6 MBR (140G)
63 293041602 1 freebsd [active] (140G)
293041665 5103 - free - (2.5M)
=> 0 293041602 ad6s1 BSD (140G)
0 2097152 1 freebsd-ufs (1.0G)
2097152 8396800 2 freebsd-swap (4.0G)
10493952 20971520 4 freebsd-ufs (10G)
31465472 2097152 5 freebsd-ufs (1.0G)
33562624 62914560 6 freebsd-ufs (30G)
96477184 62914560 7 freebsd-ufs (30G)
159391744 133649858 8 freebsd-ufs (64G)
Ideas?
--
Christian "naddy" Weisgerber na...@mips.inka.de
_______________________________________________
freebsd...@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-curre...@freebsd.org"
Paul B. Mahol
Known "problem", happens after geom_{bsd,mbr} have been
replaced with geom_part_{bsd,mbr} in /sys/$ARCH/conf/DEFAULTS
--
Paul
Marcel Moolenaar
On Dec 20, 2008, at 9:22 AM, Christian Weisgerber wrote:
> partition c: partition extends past end of unit
> bsdlabel: partition c doesn't start at 0!
> bsdlabel: An incorrect partition c may cause problems for standard
> system utilities
> partition h: partition extends past end of unit
>
> I don't know where this is coming from--the system was installed
> about a year ago with standard sysinstall--and I don't see what's
> supposed to be wrong.
Apparently sysinstall creates faulty disklabels.
--
Marcel Moolenaar
xcl...@mac.com
Christian Weisgerber
> Apparently sysinstall creates faulty disklabels.
What *is* wrong with the label on my machine?
(I think I included all the relevant details.)
--
Christian "naddy" Weisgerber na...@mips.inka.de
_______________________________________________
David O'Brien
> On Dec 20, 2008, at 9:22 AM, Christian Weisgerber wrote:
>> partition c: partition extends past end of unit
>> bsdlabel: partition c doesn't start at 0!
>> bsdlabel: An incorrect partition c may cause problems for standard system
>> utilities
>> partition h: partition extends past end of unit
>>
>> I don't know where this is coming from--the system was installed
>> about a year ago with standard sysinstall--and I don't see what's
>> supposed to be wrong.
>
Can you elaborate? I'm getting it on several machines also.
Right now, I'm trying to upgrade to a larger disk in one machine
tonight... Xmas present to myself...
What is the "approved" way to slice a disk into 4 regular slices and
than partition the slices? The only sane way to do this is (was?)
sysintall/SADE.
--
-- David (obr...@FreeBSD.org)
David O'Brien
> On Dec 20, 2008, at 9:22 AM, Christian Weisgerber wrote:
> Apparently sysinstall creates faulty disklabels.
Is this also fallout?
# fsck /dev/ad8s4f
fsck: Could not determine filesystem type
# 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
Andriy Gapon
As a general note - I don't see why GEOM_PART should complain about
"geometry does not match label" in non-verbose mode at least.
I have an external disk that can be connected either via eSATA or via
USB; depending on the type of connection its geometry is reported
differently. I guess the hardware is not helpful in this respect, but on
the other hand - who cares.
--
Andriy Gapon
Andriy Gapon
> On Sat, Dec 20, 2008 at 06:43:49PM -0800, Marcel Moolenaar wrote:
>> On Dec 20, 2008, at 9:22 AM, Christian Weisgerber wrote:
>> Apparently sysinstall creates faulty disklabels.
>
> Is this also fallout?
>
> # fsck /dev/ad8s4f
> fsck: Could not determine filesystem type
Can't comment on the above, about the below - I think that you have to
use gpart(8) once you switched a kernel to GEOM_PART, disklabel would
not "get" it.
> # 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
--
Peter Jeremy
--KdquIMZPjGJQvRdI
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable
On 2008-Dec-26 00:54:53 -0800, David O'Brien <obr...@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).
--=20
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.
--KdquIMZPjGJQvRdI
Content-Type: application/pgp-signature
Content-Disposition: inline
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.9 (FreeBSD)
iEYEARECAAYFAklVR9cACgkQ/opHv/APuIej8gCgg63iVb6GhhRLQRSAlh1r74fj
EpIAmwaYr3oFIsE0zeZ+qwvqM0fYhkyt
=PYFf
-----END PGP SIGNATURE-----
--KdquIMZPjGJQvRdI--