If rootfs isn't ZFS, current version will emit an error claiming so and fail
to initialize libbe. As a consumer, bectl -r (undocumented) can be specified
to operate on a BE independently of whether on a UFS or ZFS root.
Unbreak this for the UFS case by only erroring out the init if we can't
determine a ZFS dataset for rootfs and no BE root was specified. Consumers
of libbe should take care to ensure that rootfs is non-empty if they're
trying to use it, because this could certainly be the case.
Some check is needed before zfs_path_to_zhandle because it will
unconditionally emit to stderr if the path isn't a ZFS filesystem, which is
unhelpful for our purposes.
This should also unbreak the bectl(8) tests on a UFS root, as is the case in
Jenkins' -test runs.
MFC after: 3 days
Previously we would blindly copy the 'mountpoint' property, which includes
the altroot. The altroot needs to be snipped off prior to setting it on the
new BE, though, or you'll end up with a new BE and a mountpoint of /mnt with
altroot=/mnt
MFC after: 3 days
Add an undocumented -r option preceding the bectl subcommand to specify a BE
root to operate out of. This will remain undocumented for now, as some
caveats apply:
- BEs cannot be activated in the pool that doesn't contain the rootfs
- bectl create cannot work out of the box without the -e option right now,
since it defaults to the rootfs and cross-pool cloning doesn't work like
that (IIRC)
Plumb the BE root through to libbe(3) so that some things -can- be done to
it, e.g.
bectl -r tank/ROOT create -e default upgrade
bectl -r tank/ROOT mount upgrade /mnt
this aides in some upgrade setups where rootfs is not necessarily ZFS, and
also makes it easier/possible to regression-test bectl when combined with a
file-backed zpool.
MFC after: 3 days
Differential Revision: https://reviews.freebsd.org/D18029
libbe(3) currently uses zfs_be_root and locates which of its children is
currently mounted at "/". This is reasonable, but not correct in the case of
a chroot, for two reasons:
- chroot root may be of a different zpool than zfs_be_root
- chroot root will not show up as mounted at "/"
Fix both of these by rewriting libbe_init to work from the rootfs down.
zfs_path_to_zhandle on / will resolve to the dataset mounted at the new
root, rather than the real root. From there, we can derive the BE root/pool
and grab the bootfs off of the new pool. This does no harm in the average
case, and opens up bectl to operating on different pools for scenarios where
one may be, for instance, updating a pool that generally gets re-rooted into
from a separate UFS root or zfs bootpool.
While here, I've also:
- Eliminated the check for /boot and / to be on the same partition. This
leaves one open to a setup where /boot (and consequently, kernel/modules)
are not included in the boot environment. This may very well be an
intentional setup done by someone that knows what they're doing, we should
not kill BE usage because of it.
- Eliminated the validation bits of BEs and snapshots that enforced
'mountpoint' to be "/" -- this broke when trying to operate on an imported
pool with an altroot, but we need not be this picky.
Reported by: philip
Reviewed by: philip, allanjude (previous version)
Tested by: philip
MFC after: 3 days
Differential Revision: https://reviews.freebsd.org/D18012
The previously activated BE should have canmount=noauto set on it upon
activation of the new BE, but we previously did not touch canmount on either
old or new BE.
PR: 233113
MFC after: 3 days
Most easily reproducible by attempting to activate the currently activated
BE, one would get a "not a cloned filesystem" error instead of success or a
sane message.
PR: 232488
MFC after: 3 days
This allows older BEs to be destroyed as they become replaced by a BE
created from them: e.g.
bectl create -e brokenworld fixedworld
bectl activate fixedworld
bectl destroy brokenworld
Submitted by: Shawn Webb
Approved by: re (gjb)
Obtained from: HardenedBSD (5948c0581e)
Some paths through be_exists will set the error state, others will not
There are multiple reasons that a call can fail, so clean it up a bit: all
paths now return an appropriate error code so the caller can attempt to
distinguish between a BE legitimately not existing and just having the wrong
mountpoint. The caller is expected to bubble the error through to the
internal error handler as needed.
This fixes some unfriendliness with bectl(8)'s activate subcommand, where
it might fail due to a bad mountpoint but the only message output is a
generic "failed to activate" message.
Approved by: re (gjb)
vermaden (maintainer of beadm) points out the following inconsistencies:
- "missing command" is not printed prior to usage if the error is simply a
missing command; this should be obvious from the context
- "bectl rename" isn't using the "don't unmount" flag (zfs rename -u), so
the active BE can't be renamed. It doesn't make sense in our context to
*not* use -u, so use it.
Documentation updates reflect the above and note an inconsistency with the
'destroy' command that is consistent with other parts of the base system.
A fix for libbe(3) not properly being installed to /lib is included.
SHLIBDIR should have been added when it was moved in r337995.
Approved by: re (kib)
Previously, we only validated names for character restrictions. This is
helpful, but we should've also checked length restrictions- dataset names
must be restricted to MAXNAMELEN.
While here, move validation before doing a bunch of concatenations and fix
error handling in be_rename. It was previously setting the error state based
on return value from a libzfs function, which is wrong: libzfs errors don't
necessarily match cleanly to libbe errors. This would cause the assertion in
be_error to hit when the error was printed.
Deleting the temp snapshot isn't immediately possible because it's the
origin of the newly imported boot environment. However, this is trivially
solved by opening the new boot environment and promoting it. The roles are
now reversed and the temp snapshot/dataset may be completely destroyed.
Remove the BUGS from libbe(3) and bectl(8).
The mostly-undocumented 'add' functionality, from initial read-through, is
intended for construction of deep ("bdrewery style") boot environments.
However, it's mostly broken at this point. `#if SOON` it out on both sides
so that we're not exposing a broken API/feature.
Work will resume on it in due time.
be_add_child functionality gets split out into separate places as a bonus.
A lot of places here we'll gloss over libzfs errors, because they shouldn't
be happening given the conditions that we're operating under. "Unknown
error" is what I'm intending to use for the moment to indicate an
exceptional circumstance- exceptional enough that we can't tell the consumer
did because we're not so certain that they did anything.
- File names don't necessarily need to be repeated
- Add SPDX tags
- Add a missing copyright for Kyle Kneitinger in bectl.8, originally written
by him in GSoC 2017; his standard copyright notice has been copied from
other files within the same directory to remain consistent with how he
clearly wished to portray it
Loader is still relied upon at the beginning of libbe to specify the be
root, but we can derive from that the primary zpool and any vdevs that we
need to set nextboot bits on.
This lets me successfully `bectl activate -t test`, but UEFI loader doesn't
quite yet understand so it's effectively defunct.
This also accomplishes the following:
- Proxy through zfs_nicenum as be_nicenum, because it looks better than
humanize_number and would presumably be useful to other libbe consumers.
- Rename be_get_snapshot_props to be_get_dataset_props, make it more useful
Based on the idea that we shouldn't have all-new library and utility going
into base that need WARNS=1...
- Decent amount of constification
- Lots of parentheses
- Minor other nits
This makes us more resilient to a rename of the bootfs, but still wouldn't
withstand pool renames or guid renames. More importantly, this allows `bectl
create <foo>` work out of the box to create a boot environment based on the
currently booted one.
- Rename 'active' to 'rootfs', which is used in other places to describe the
currently booted (or about to be booted) BE.
- Add 'bootfs', which indicates the next boot environment to be booted. This
is pulled from the BOOTFS zpool property.
- Go ahead and keep an open handle to the active zpool. We might need to
enumerate datasets, get properties, and set properties (e.g. bootfs)
throughout other libbe bits, and a single handle isn't overly expensive.
