FreeBSD source tree https://cgit-dev.freebsd.org/src/atom?h=release%2F12.3.0 2020-11-14T15:26:18Z 2020-11-14T15:26:18Z Kyle Evans kevans@FreeBSD.org 2020-11-14T15:26:18Z urn:sha1:fbeb1ad7f01e63101b6d9cc7ab1d5927e8f991b7 libbe will never need to mutate these as we either process them into a local buffer or we just don't touch them and write to a separate out argument. 2020-11-14T15:21:20Z Kyle Evans kevans@FreeBSD.org 2020-11-14T15:21:20Z urn:sha1:1a672d9c1e76675ce28342ac4740e3446231fe04 r366820: libbe(3): document be_snapshot() While toying around with lua bindings for libbe(3), I discovered that I apparently never documented this, despite having documented be_is_auto_snapshot_name that references it. r366821: libbe(3): install MLINKS for all of the functions provided 2020-02-07T21:57:27Z Kyle Evans kevans@FreeBSD.org 2020-02-07T21:57:27Z urn:sha1:1d1ed1a5d73fd91fb6dfbd4dda0ae2f22593c9cf 2019-10-20T22:05:57Z Kyle Evans kevans@FreeBSD.org 2019-10-20T22:05:57Z urn:sha1:8eec5cf12da527935343bc1b4fbb58885ba7f357 r353644: libbe(3): add needed bits for be_destroy to auto-destroy some origins New BEs can be created from either an existing snapshot or an existing BE. If an existing BE is chosen (either implicitly via 'bectl create' or explicitly via 'bectl create -e foo bar', for instance), then bectl will create a snapshot of the current BE or "foo" with be_snapshot, with a name formatted like: strftime("%F-%T") and a serial added to it. This commit adds the needed bits for libbe or consumers to determine if a snapshot names matches one of these auto-created snapshots (with some light validation of the date/time/serial), and also a be_destroy flag to specify that the origin should be automatically destroyed if possible. A future commit to bectl will specify BE_DESTROY_AUTOORIGIN by default so we clean up the origin in the most common case, non-user-managed snapshots. r353646: bectl(8): destroy: use BE_DESTROY_AUTOORIGIN if -o is not specified -o will force the origin to be destroyed unconditionally. BE_DESTROY_AUTOORIGIN, on the other hand, will only destroy the origin if it matches the format used by be_snapshot. This lets us clean up the snapshots that are clearly not user-managed (because we're creating them) while leaving user-created snapshots in place and warning that they're still around when the BE created goes away. r353663: libbe(3): Fix destroy of imported BE w/ AUTOORIGIN Imported BE, much like the activated BE, will not have an origin that we can fetch/examine for destruction. be_destroy should not return BE_ERR_NOORIGIN for failure to get the origin property for BE_DESTROY_AUTOORIGIN, because we don't really know going into it that there's even an origin to be destroyed. BE_DESTROY_NEEDORIGIN has been renamed to BE_DESTROY_WANTORIGIN because only a subset of it *needs* the origin, so 'need' is too strong of verbiage. This was caught by jenkins and the bectl tests, but kevans failed to run the bectl tests prior to commit. 2019-04-28T03:49:40Z Kyle Evans kevans@FreeBSD.org 2019-04-28T03:49:40Z urn:sha1:f1ab1b71d6c92f4c96642e7ab90f9460ea6ec592 r346545: libbe(3): allow creation of arbitrary depth boot environments libbe currently only provides an API to create a recursive boot environment, without any formal support for intentionally limiting the depth. This changeset adds an API, be_create_depth, that may be used to arbitrarily restrict the depth of the new BE. r346546: libbe(3): Add a test for be creation r346680: libbe(3): Copy received properties as well This was inherently broken on send|recv datasets. r346700: libbe(3): Fix mis-application of patch (SHLIBDIR) Rob's patch in D18564 cemented the SHLIBDIR because bsd.own.mk (included by src.opts.mk) sets it to /usr/lib. r346546 did somehow not apply this part of the patch, leaving it to get installed to the wrong place and subsequently removed via ObsoleteFiles. r346705: libbe(3): Fix libcompat build SHLIBDIR should still be optionally set, just before src.opts.mk is included so that libcompat can properly override it. This fixes lib32 failures reported by both Jenkins and Michael Butler. 2019-04-08T17:41:39Z Kyle Evans kevans@FreeBSD.org 2019-04-08T17:41:39Z urn:sha1:fa88eafaf8cf5b055f6907e8fc09ad68462bc523 r343335: libbe(3): simplify import, allow replication streams Previously, we directly used libzfs_core's lzc_receive to import to a temporary snapshot, then cloned the snapshot and setup the properties. This failed when attempting to import replication streams with questionable error. libzfs's zfs_receive is a much better fit here, so we now use it instead with the destination dataset and let libzfs take care of the dirty details. be_import is greatly simplified as a result. r343977: libbe(3): Add a destroy option for removing the origin Currently origin snapshots are left behind when a BE is destroyed, whether it was an auto-created snapshot or explicitly specified via, for example, `bectl create -e be@mysnap ...`. Removing it automatically could be argued as a POLA violation in some circumstances, so provide a flag to be_destroy for it. An accompanying option will be added to bectl(8) to utilize this. Some minor style/consistency nits in the affected areas also addressed. r343993: bectl(8): Add -o flag to destroy to clean up the origin snapshot of BE We can't predict when destruction of origin is needed, and currently we have a precedent for not prompting for things. Leave the decision up to the user of bectl(8) if they want the origin snapshot to be destroyed or not. Emits a warning when -o isn't used and an origin snapshot is left to be cleaned up, for the time being. This is handy when one drops the -o flag but really did want to clean up the origin. A couple of -e ignore's have been sprinkled around the test suite for places that we don't care that the origin's not been cleaned up. -o functionality tests will be added in the future, but are omitted for now to reduce conflicts with work in flight to fix bits of the tests. r343994: bectl(8): commit missing test modifications from r343993 r344034: libbe(3): Belatedly note the BE_DESTROY_ORIGIN option added in r343977 r344084: libbe(3): Fix be_destroy behavior w.r.t. deep BE snapshots and -o be_destroy is documented to recursively destroy a boot environment. In the case of snapshots, one would take this to mean that these are also recursively destroyed. However, this was previously not the case. be_destroy would descend into the be_destroy callback and attempt to zfs_iter_children on the top-level snapshot, which is bogus. Our alternative approach is to take note of the snapshot name and iterate through all of fs children of the BE to try destruction in the children. The -o option is also fixed to work properly with deep BEs. If the BE was created with `bectl create -e otherDeepBE newDeepBE`, for instance, then a recursive snapshot of otherDeepBE would have been taken for construction of newDeepBE but a subsequent destroy with BE_DESTROY_ORIGIN set would only clean up the snapshot at the root of otherDeepBE: ${BEROOT}/otherDeepBE@... The most recent iteration instead pretends not to know how these things work, verifies that the origin is another BE and then passes that back through be_destroy to DTRT when snapshots and deep BEs may be in play. r345302: bectl(8): change jail command to execute jail(8) The jail(8) command provides a variety of jail pseudo-parameters that are useful to consumers of bectl, mount.devfs being the most-often-requested paramater by bectl users. command, exec.start, nopersist, and persist may not be specified via -o to bectl. The command/exec.start remains passed as it always has at the end of bectl, and persistence is dictated by -b/-U bectl jail arguments. r345769: libbe: Fix zfs_is_mounted check w/ snapshots 'be_destroy' can destroy a boot environment (by name) or a given snapshot. If the target to be destroyed is a dataset, check if it's mounted. We don't want to check if the origin dataset is mounted when destroying a snapshot. PR: 236043 2019-01-03T18:30:36Z Kyle Evans kevans@FreeBSD.org 2019-01-03T18:30:36Z urn:sha1:8bc0d4d82c563affac2bc9149823e1d006a4b6bb r340722 (0mp): libbe(3): Put each error value in separate line. As requested by a TODO in the source code. r340723 (0mp): Cross-reference libbe(3) and bectl(8). Those two manual pages are already referencing each other in the HISTORY sections, which people might skip. Mention those manual pages explicitly in the SEE ALSO sections. Also, remove a reference to be(1) from libbe(3). r342466: bectl: use jail id as the default jail name for a boot environment By default, bectl is setting the jail 'name' parameter to the boot environment name, which causes an error when the boot environment name is not a valid jail name. With the attached fix, when no name is supplied, the default jail name will be the jail id - this is is the same behavior as the jail command. Additionally, this commit addresses two other bugs that prevented unjailing in scenarios where the jail name does not match the boot environment name: 1. In 'bectl_locate_jail', 'mountpoint' is used to resolve the boot environment path, but really 'mounted' should be used. 'mountpoint' is the path where the zfs dataset will be mounted. 'mounted' is the path where the dataset is actually mounted. 2. in 'bectl_search_jail_paths', 'jail_getv' would fail after the first call. Which is fine, if the boot environment you're unjailing is the next one up. According to 'man jail_getv', it's expecting name and value strings. 'jail_getv' is being passed an integer for the lastjid, so amend that to use a string instead. Test cases have been amended to reflect the bugs found. PR: 233637 2018-11-22T01:25:44Z Kyle Evans kevans@FreeBSD.org 2018-11-22T01:25:44Z urn:sha1:fa6c19ac9a2137471c4f07ccb2e8995924c8a61b 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. 2018-09-01T02:22:26Z Kyle Evans kevans@FreeBSD.org 2018-09-01T02:22:26Z urn:sha1:162ec569493ba1919857c22a957c97700246da14 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) 2018-08-24T20:44:58Z Kyle Evans kevans@FreeBSD.org 2018-08-24T20:44:58Z urn:sha1:8369ba427a9a4db4c4886fb2a6d7a7dae00de707 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)