<?xml version="1.0"?>
<?xml-stylesheet type="text/xsl" href="/rss.xsl.xml"?>
<rss version="2.0" xmlns:dc="http://purl.org/dc/elements/1.1/">
<channel>
    <title>Changes in bectl</title>
    <description></description>
    <language>en</language>
    <copyright>Copyright 2015</copyright>
    <generator>Java</generator><item>
        <title>ad8c522b - MFC r351813, r352092: bectl(8) list sorting</title>
        <link>http://172.16.0.5:8080/history/freebsd-12.1/sbin/bectl/#ad8c522b</link>
        <description>MFC r351813, r352092: bectl(8) list sortingMFC r351813: bectl(8): implement sorting for &apos;bectl list&apos; outputAllow &apos;bectl list&apos; to sort output by a given property name. The propertyname is passed in using a command-line flag, &apos;-c&apos; for ascending order and&apos;-C&apos; for descending order. The properties allowed to sort by are:- name (the default output, even if &apos;-c&apos; or &apos;-C&apos; are not used)- creation- origin- used- usedds- usedsnap- usedrefreservThe default output for &apos;bectl list&apos; is now ascending alphabetical order ofBE name.To sort by creation time from earliest to latest, the command would be&apos;bectl list -c creation&apos;MFC r352092: bectl(8): initialize reverse earlierThis turns into a warning in GCC 4.2 that &apos;reverse&apos; may be useduninitialized in this function. While I don&apos;t immediately see where it&apos;sdeciding this from (there&apos;s only two paths that make column != NULL, andthey both set reverse), initializing reverse earlier is good for clarity.

            List of files:
            /freebsd-12.1/sbin/bectl/bectl_list.c</description>
        <pubDate>Sun, 15 Sep 2019 02:00:00 +0000</pubDate>
        <dc:creator>Kyle Evans &lt;kevans@FreeBSD.org&gt;</dc:creator>
    </item>
<item>
        <title>2b908947 - MFC r352211: bectl(8): Add a &quot;check&quot; command</title>
        <link>http://172.16.0.5:8080/history/freebsd-12.1/sbin/bectl/#2b908947</link>
        <description>MFC r352211: bectl(8): Add a &quot;check&quot; commandThis command simply returns 0 at the moment and explicitly takes noarguments. This should be used by utilities wanting to see if bectl canoperate on the system they&apos;re running, or with a specific root (`bectl -r`).It may grow more checks than &quot;will libbe successfully init&quot; in the future,but for now this is enough as that checks for the dataset mounted at &quot;/&quot; andthat it looks capable of being a BE root (e.g. it&apos;s not a top-level dataset)bectl commands can now specify if they want to be silent, and this will turnoff libbe_print_on_error so they can control the output as needed. This isalready used in `bectl check`, and may be turned on in the future for someother commands where libbe errors are better suppressed as the failure modemay be obvious.

            List of files:
            /freebsd-12.1/sbin/bectl/bectl.8/freebsd-12.1/sbin/bectl/bectl.c</description>
        <pubDate>Sun, 15 Sep 2019 02:00:00 +0000</pubDate>
        <dc:creator>Kyle Evans &lt;kevans@FreeBSD.org&gt;</dc:creator>
    </item>
<item>
        <title>0205de32 - MFC r348328: bectl(8): Address Coverity complaints</title>
        <link>http://172.16.0.5:8080/history/freebsd-12.1/sbin/bectl/#0205de32</link>
        <description>MFC r348328: bectl(8): Address Coverity complaintsCID 1400451: case 0 is missing a break/return and falling through to thedefault case.  waitpid(0, ...) makes little sense in the child, we likelywanted to terminate immediately.CID 1400453: size argument uses sizeof(char **) instead of sizeof(char *)and is assigned to a char **; sizeof&apos;s match but &quot;this isn&apos;t a portableassumption&quot;.CID:	1400451, 1400453

            List of files:
            /freebsd-12.1/sbin/bectl/bectl_jail.c</description>
        <pubDate>Fri, 26 Jul 2019 01:00:00 +0000</pubDate>
        <dc:creator>Kyle Evans &lt;kevans@FreeBSD.org&gt;</dc:creator>
    </item>
<item>
        <title>686d5664 - MFC r349380, r349383, r349455: bectl(8)/libbe(3) fixes</title>
        <link>http://172.16.0.5:8080/history/freebsd-12.1/sbin/bectl/#686d5664</link>
        <description>MFC r349380, r349383, r349455: bectl(8)/libbe(3) fixesr349380:libbe(3): mount: the BE dataset is mounted at /Other parts of libbe(3) were fairly strict on the mountpoint property of theBE dataset, and be_mount was not much better. It was improved in r347027 toallow mountpoint=none for depth==0, but this bit was still sensitive tomountpoint != / and mountpoint != none. Given that other parts of libbe(3)no longer restrict the mountpoint property here, and the rest of the basesystem is generally OK and will assume that a BE is mounted at /, let&apos;s dothe same.r349383:libbe(3): restructure be_mount, skip canmount check for BE datasetFurther cleanup after r349380; loader and kernel will both ignore canmounton the root dataset as well, so we should not be so strict about it whenmounting it. be_mount is restructured to make it more clear that depth==0 isspecial, and to not try fetching these properties that we won&apos;t care about.r349455:bectl(8): create non-recursive boot environmentsbectl advertises that it has the ability to create recursive andnon-recursive boot environments. This patch implements that functionalityusing the be_create_depth API provided by libbe. With this patch, bectl nowworks as bectl(8) describes in regards to creating recursive/non-recursiveboot environments.

            List of files:
            /freebsd-12.1/sbin/bectl/tests/bectl_test.sh</description>
        <pubDate>Fri, 26 Jul 2019 01:00:00 +0000</pubDate>
        <dc:creator>Kyle Evans &lt;kevans@FreeBSD.org&gt;</dc:creator>
    </item>
<item>
        <title>526ad58e - bectl(8): Split list functionality out into its own file as well</title>
        <link>http://172.16.0.5:8080/history/freebsd-12.1/sbin/bectl/#526ad58e</link>
        <description>bectl(8): Split list functionality out into its own file as well

            List of files:
            /freebsd-12.1/sbin/bectl/bectl.h</description>
        <pubDate>Mon, 06 Aug 2018 03:00:00 +0000</pubDate>
        <dc:creator>Kyle Evans &lt;kevans@FreeBSD.org&gt;</dc:creator>
    </item>
<item>
        <title>fa6c19ac - MFC r340507-r340508, r340592-r340594, r340635-r340636: bectl(8) fixes</title>
        <link>http://172.16.0.5:8080/history/freebsd-12.1/sbin/bectl/#fa6c19ac</link>
        <description>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 &quot;/&quot;. 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 &quot;/&quot;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&apos;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&apos;re doing, we should  not kill BE usage because of it.- Eliminated the validation bits of BEs and snapshots that enforced  &apos;mountpoint&apos; to be &quot;/&quot; -- 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&apos;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&apos;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 &apos;mountpoint&apos; property, which includesthe altroot. The altroot needs to be snipped off prior to setting it on thenew BE, though, or you&apos;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 &quot;are create/destroy actuallyreflected properly&quot;r340635:libbe(3): Handle non-ZFS rootfs betterIf rootfs isn&apos;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&apos;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&apos;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&apos;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&apos; -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/Makefile/freebsd-12.1/sbin/bectl/tests/Makefile</description>
        <pubDate>Thu, 22 Nov 2018 01:00:00 +0000</pubDate>
        <dc:creator>Kyle Evans &lt;kevans@FreeBSD.org&gt;</dc:creator>
    </item>
</channel>
</rss>
