the GEOM_BSD class -- to translate the absolute offsets in the label to
relative ones. This makes bslabel(8) work correctly with GEOM_PART and
also when the BSD label is nested under arbitrary partitioning schemes.
Inspired by: Eygene Ryabinkin <rea-fbsd@codelabs.ru>
Approved by: re (kib)
size and the sector size.
- Fix a bug where bsdlabel would try to read a regular file using the geom_bsd
class.
Quick review by: phk
Approved by: pjd (mentor)
section (if nothing had been specified, or if the auto type had
been specified, a default layout is used).
PR: docs/116047
Submitted by: Ian Smith <smithi at nimnet dot asn dot au>
Minor modifications by me.
- Somewhat improve wording.
- Change the layout of the EXAMPLES section so that descriptions
come before example, as in most other manpages.
- Fix a bad example that edits a label using a `c' partition.
replace them with references to newfs(8) which documents them.
- Remove mentions of LFS support for which was retired in 1998.
- Regenerate an example output.
PR: docs/84913
MFC after: 3 days
to take into account the new default of starting the first partition
after the boot blocks instead of at sector 0. If you used automatic
sizing when the first partition did not start at 0, you would get
an error that the automatically sized partition extended beyond the
end of the disk.
Note that there are probably still many more complex cases where
automatic sizing and placement will not work (e.g. non-contiguous
or out of order partitions).
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
MFC after: 1 week
0xffffffff sectors. Document this limit and avoid installing bogus
labels on disks with more sectors.
Allowing the installation of labels addressing as much of the disk as
possiable may be a useful addition in some situations, but this was easy
to implement and should reduce confusion.
PR: bin/71408
length, and flags fields at the end of the SRM boot sector so that SRM can
find the bootstrap code. This fixes bsdlabel -m alpha to generate bootable
disklabels.
Reviewed by: phk
and the logic for setting them according to the partition size.
Instead, unspecified filesystem values are left at 0 so that newfs
will use its own defaults. It just caused confusion to have the
defaults duplicated in two different places.
Reviewed by: phk
hinge on the "verb" parameter which the class gets to interpret as
it sees fit.
Move the entire request into the kernel and move changed parameters
back when done.
