| #
fa6c19ac |
| 22-Nov-2018 |
Kyle Evans <[email protected]> |
MFC r340507-r340508, r340592-r340594, r340635-r340636: bectl(8) fixes
r340507:
libbe(3): rewrite init to support chroot usage
libbe(3) currently uses zfs_be_root and locates which of its children i
MFC r340507-r340508, r340592-r340594, r340635-r340636: bectl(8) fixes
r340507:
libbe(3): rewrite init to support chroot usage
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
Differential Revision: https://reviews.freebsd.org/D18012
r340508:
libbe(3): Rewrite be_unmount to stop mucking with getmntinfo(2)
Go through the ZFS layer instead; given a BE, we can derive the dataset,
zfs_open it, then zfs_unmount. ZFS takes care of the dirty details and
likely gets it more correct than we did for more interesting setups.
r340592:
bectl(3)/libbe(3): Allow BE root to be specified
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.
Differential Revision: https://reviews.freebsd.org/D18029
r340593:
libbe(3): Properly account for altroot when creating new BEs
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
r340594:
bectl(8): Add some regression tests
These tests operate on a file-backed zpool that gets created in the kyua
temp dir. root and ZFS support are both required for these tests. Current
tests cover create, destroy, export/import, jail, list (kind of), mount,
rename, and jail.
List tests should later be extended to cover formatting and the different
list flags, but for now only covers basic "are create/destroy actually
reflected properly"
r340635:
libbe(3): Handle non-ZFS rootfs better
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.
r340636:
bectl(8) tests: attempt to load the ZFS module
Observed in a CI test image, bectl_create test will run and be marked as
skipped because the module is not loaded. The first zpool invocation will
automagically load the module, but bectl_create is still skipped. Subsequent
tests all pass as expected because the module is now loaded and everything
is OK.
show more ...
|
| #
f2fdf2a1 |
| 13-Aug-2018 |
Kyle Evans <[email protected]> |
libbe(3)/bectl(8): Remove now-redundant include paths
These were previously necessary because the libnvpair and libzfs_core
includes were not installed into the SYSROOT, being a part of the copies
t
libbe(3)/bectl(8): Remove now-redundant include paths
These were previously necessary because the libnvpair and libzfs_core
includes were not installed into the SYSROOT, being a part of the copies
target in include/Makefile rather than being installed with the library.
This was fixed in r337696 and the headers are now installed properly, so we
may let go of the cruft.
show more ...
|
| #
d694059f |
| 06-Aug-2018 |
Kyle Evans <[email protected]> |
bectl(8): bectl jail improvements
- Support passing arbitrary jail arguments via -o
- Split the related (and rewritten since the GSoC) jail bits out into a new
bectl_jail.c file, to reduce clutter
bectl(8): bectl jail improvements
- Support passing arbitrary jail arguments via -o
- Split the related (and rewritten since the GSoC) jail bits out into a new
bectl_jail.c file, to reduce clutter in bectl.c
- Don't use RFC 1918 IP space [0]; we'll instead set no default IPv4 and let
the user pass in any address options they wish via -o
Reported by: rgrimes [0], Shawn Webb [0]
show more ...
|
| #
ad765da4 |
| 26-Jul-2018 |
Kyle Evans <[email protected]> |
bectl(8): Support unjailing a boot environment
The given parameter may either be a jid, jail name, or a BE name. In all
cases, the parameter will be resolved to a jid and bectl(8) will
sanity-check
bectl(8): Support unjailing a boot environment
The given parameter may either be a jid, jail name, or a BE name. In all
cases, the parameter will be resolved to a jid and bectl(8) will
sanity-check that there's actually a BE mounted at the requested jail root
before invoking jail_remove(2).
show more ...
|