Date: Fri, 14 Jan 2005 07:47:32 +0000 (UTC) From: "Ralf S. Engelschall" <rse@FreeBSD.org> To: src-committers@FreeBSD.org, cvs-src@FreeBSD.org, cvs-all@FreeBSD.org Subject: cvs commit: src/sbin/bsdlabel bsdlabel.c Message-ID: <200501140747.j0E7lW78048673@repoman.freebsd.org>
next in thread | raw e-mail | index | archive | help
rse 2005-01-14 07:47:32 UTC
FreeBSD src repository
Modified files: (Branch: RELENG_5)
sbin/bsdlabel bsdlabel.c
Log:
MFC: revision 1.110
Fix the derivation of the GEOM name from the specified device name by
complementing the existing special case of a not existing /dev prefix
with the recognition of an already existing /dev prefix.
This implicitly solves the following two issues related to working on
GEOM devices /dev/foo/bar (which have the GEOM provider name "foo/bar")
with the expected commands like "bsdlabel /dev/foo/bar":
1. the error "Geom not found" when trying to write or edit the BSD
label (because previously the incorrect GEOM name "bar" instead of
"foo/bar" was derived from "/dev/foo/bar").
2. the multiple times reported "magically introduced" partition offset
of 63 blocks and the resulting errors like "partition extends past
end of unit" and "partition c doesn't start at 0!".
This implicitly resulted because bsdlabel(8) determines the "MBR
offset" via GEOM and (intentionally) silently falls back to an offset
of 0 if it could not be queried (which is the case if the name was
incorrectly derived).
Usually (at least on PCs) the offset for the first slice is 63 blocks
and bsdlabel(8) automatically subtracts them from the absolute
offsets in the read on-disk BSD label, resulting in the display of an
effective offset of 0. If the GEOM query fails, the assumed offset of
0 is subtracted and an incorrect effective offset of 63 is displayed
and tried to be worked upon.
Reviewed by: pjd
Revision Changes Path
1.108.2.2 +3 -0 src/sbin/bsdlabel/bsdlabel.c
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?200501140747.j0E7lW78048673>