en Copyright 2015 Java http://172.16.0.5:8080/history/freebsd-12.1/sbin/bectl/tests/Makefile#fa6c19ac MFC r340507-r340508, r340592-r340594, r340635-r340636: bectl(8) fixesr340507:libbe(3): rewrite init to support chroot usagelibbe(3) currently uses zfs_be_root and locates which of its children iscurrently mounted at "/". This is reasonable, but not correct in the case ofa 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 newroot, rather than the real root. From there, we can derive the BE root/pooland grab the bootfs off of the new pool. This does no harm in the averagecase, and opens up bectl to operating on different pools for scenarios whereone may be, for instance, updating a pool that generally gets re-rooted intofrom 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: philipReviewed by: philip, allanjude (previous version)Tested by: philipDifferential Revision: https://reviews.freebsd.org/D18012r340508: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 andlikely gets it more correct than we did for more interesting setups.r340592:bectl(3)/libbe(3): Allow BE root to be specifiedAdd an undocumented -r option preceding the bectl subcommand to specify a BEroot to operate out of. This will remain undocumented for now, as somecaveats 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 toit, e.g.bectl -r tank/ROOT create -e default upgradebectl -r tank/ROOT mount upgrade /mntthis aides in some upgrade setups where rootfs is not necessarily ZFS, andalso makes it easier/possible to regression-test bectl when combined with afile-backed zpool.Differential Revision: https://reviews.freebsd.org/D18029r340593:libbe(3): Properly account for altroot when creating new BEsPreviously we would blindly copy the 'mountpoint' property, which includesthe altroot. The altroot needs to be snipped off prior to setting it on thenew BE, though, or you'll end up with a new BE and a mountpoint of /mnt withaltroot=/mntr340594:bectl(8): Add some regression testsThese tests operate on a file-backed zpool that gets created in the kyuatemp dir. root and ZFS support are both required for these tests. Currenttests cover create, destroy, export/import, jail, list (kind of), mount,rename, and jail.List tests should later be extended to cover formatting and the differentlist flags, but for now only covers basic "are create/destroy actuallyreflected properly"r340635:libbe(3): Handle non-ZFS rootfs betterIf rootfs isn't ZFS, current version will emit an error claiming so and failto initialize libbe. As a consumer, bectl -r (undocumented) can be specifiedto 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'tdetermine a ZFS dataset for rootfs and no BE root was specified. Consumersof libbe should take care to ensure that rootfs is non-empty if they'retrying to use it, because this could certainly be the case.Some check is needed before zfs_path_to_zhandle because it willunconditionally emit to stderr if the path isn't a ZFS filesystem, which isunhelpful for our purposes.This should also unbreak the bectl(8) tests on a UFS root, as is the case inJenkins' -test runs.r340636:bectl(8) tests: attempt to load the ZFS moduleObserved in a CI test image, bectl_create test will run and be marked asskipped because the module is not loaded. The first zpool invocation willautomagically load the module, but bectl_create is still skipped. Subsequenttests all pass as expected because the module is now loaded and everythingis OK. List of files: /freebsd-12.1/sbin/bectl/tests/Makefile Thu, 22 Nov 2018 01:25:44 +0000 Kyle Evans <kevans@FreeBSD.org>