Currently beadm is in Ports as sysutils/beadm. What do you think about including it in the base? % ls -lh /usr/local/man/man1/beadm.1.gz /usr/local/sbin/beadm -r--r--r-- 1 root wheel 1.8K 2018.07.10 04:45 /usr/local/man/man1/beadm.1.gz -r-xr-xr-x 1 root wheel 28K 2018.07.10 04:45 /usr/local/sbin/beadm Basically its just these two files.
Kyle was working on a potential GSoC-originated C language replacement library plus command program for beadm, but I don't know if it is viable. beadm appears to be plain bourne sh with a suitable license, so I don't think there's any clear reason it isn't suitable for inclusion in base. (I don't use ZFS myself.)
Also adding Allan to CC, as it was originally his student's project. My understanding is that there was a strong desire to have boot environment functionality written as a C library for use by 'other things', with a C front-end using it that emulates the output of beadm. I've no idea what these potential 'other things' are, or if that's even an already-enumerated list. The work I've done on it may be found here [1], mostly in sbin/bectl and lib/libbe with build bits for the latter in cddl/lib/libbe. It generally works at the moment and is a superset of beadm functionality with, AFAIK, hints taken from beadm's help for other useful functionality (e.g. it has built-in ability to create a jail from a given boot environment, and it can also export/import boot environments). Current work is focused on `bectl list`, which kind of works at a basic level but effectively ignores -a/-s/-D/-H and the 'space' field isn't formatted as nicely as beadm. [1] https://svnweb.freebsd.org/base/projects/bectl/
I would like to have something before 12.0. Kyle do you thing that your work will be finished before it?
(In reply to Mariusz Zaborski from comment #3) Yeah, I think so. The following is my tentative list of 'things to accomplish before merging into head/ for wider feedback': - Complete `bectl list` - Remove some `bectl jail` assumptions (e.g. ipv4 address in RFC 1918 space), perhaps add -o flag to allow user to set arbitrary jail arguments These are maybe done by middle of next week if I can shovel together enough free time to deal with jail stuff. Most of the libbe(3) API is there to finish `bectl list`, with the exception of enumerating all snapshots for the different boot environments. The basic functionality seems to work well enough for me at this point.
(In reply to Kyle Evans from comment #4) As an update to this- I've got the list and jail cleanup done. I intend to make a pass and clean up the error reporting/handling in libbe with the goal of merging it all to head by Wednesday/Thursday time frame.
libbe(3) and beadm(8) have been merged into head as of r337667.
So I guess we can close this bug.
(In reply to Mariusz Zaborski from comment #7) I haven't yet tested the bectl but I assume that even if it has any bugs I will post them in separate PRs and if not all features of beadm are implemented in bectl then they can be implemented in the future if they are needed. In other words I think this PR can be closed. Regards.
(In reply to vermaden from comment #8) Hi, Please do reach out and CC me in any bectl issues. =) beadm is a great role-model, and I did my best when expanding the bectl leftover from GSoC 2017 to match beadm's behavior, but I know I missed some major details as I don't do much of anything fancy with boot environments.
(In reply to Kyle Evans from comment #9) Sure, I am waiting for 12.0-ALPHA2 ISO images to appear so I can download them and test bectl ;)
I have tried bectl in 12-ALPHA2 and it worked ok for me. One more question to not start another PR. Does bectl/libbe support separate ZFS boot pool or only single ZFS root pool? Regards.
(In reply to vermaden from comment #11) Heh, trick question. =D At the moment, neither of them truly support multiple boot pools. However: libbe(3) could be trivially fixed to support multiple boot pools. You'd need multiple libbe handles to accommodate, and libbe_init would need a pretty minor re-work. At the moment it'll always use zfs_be_root from kenv, but it would not be a hard re-work to accept the BE root to use and fallback to zfs_be_root if NULL. Everything else assumes whatever root is decided in libbe_init. bectl(8) is a slightly different story, I guess, depending on how you think this should work. We could add an -r argument before subcommand to specify a BE root to work with, but I'm not sure if we're expecting any more intelligent interaction than that. (e.g. bectl list being able to deduce BE roots in other pools)
(In reply to vermaden from comment #11) It is not possible to take a consistent snapshot across 2 pools, so having /boot as a separate pool doesn't really work for boot environments, since your snapshot of / will not include your kernel.
(In reply to Allan Jude and Kyle Evans) Thanks for comments gentlemen, that is what I thought but wanted to be sure. I do not need that feature but I was often asked about BEADM for the same thing so that is why I asked :)
(In reply to vermaden from comment #14) Given that, I might consider breaking the libbe(3) API before freeze hits to allow libbe_init to take a BE Root to use instead of zfs_be_root so front-end interaction with different roots can be added later and backported.
Proposal - remove the *missing command* text when run without arguments. Currently: # bectl missing command usage: bectl ( -h | -? | subcommand [args...] ) bectl activate [-t] beName bectl create [-e nonActiveBe | -e beName@snapshot] beName bectl create beName@snapshot bectl destroy [-F] beName | beName@snapshot⟩ bectl export sourceBe bectl import targetBe bectl jail [ -o key=value | -u key ]... bootenv bectl list [-a] [-D] [-H] [-s] bectl mount beName [mountpoint] bectl rename origBeName newBeName bectl { ujail | unjail } ⟨jailID | jailName | bootenv) bectl { umount | unmount } [-f] beName Proposal: # bectl usage: bectl ( -h | -? | subcommand [args...] ) bectl activate [-t] beName bectl create [-e nonActiveBe | -e beName@snapshot] beName bectl create beName@snapshot bectl destroy [-F] beName | beName@snapshot⟩ bectl export sourceBe bectl import targetBe bectl jail [ -o key=value | -u key ]... bootenv bectl list [-a] [-D] [-H] [-s] bectl mount beName [mountpoint] bectl rename origBeName newBeName bectl { ujail | unjail } ⟨jailID | jailName | bootenv) bectl { umount | unmount } [-f] beName
root@fbsd12:~ # bectl rename safe new boot environment is already mounted failed to rename bootenv safe to new Its possible to rename mounted as / dataset with this ZFS command: root@fbsd12:~ # bectl list BE Active Mountpoint Space Created safe NR / 188K 2018-08-18 02:32 default - - 427M 2018-08-18 02:26 root@fbsd12:~ # zfs list | grep safe zroot/ROOT/safe 108K 6.85G 427M / root@fbsd12:~ # zfs rename -u zroot/ROOT/safe zroot/ROOT/new Its then listed as default in bectl: root@fbsd12:~ # bectl list BE Active Mountpoint Space Created new NR / 188K 2018-08-18 02:32 default - - 427M 2018-08-18 02:26
Do we want/need confirmation for delete commands like with beadm? I aks because maybe its consisten with other FreeBSD tools to NOT ask (admin knows what he is doing ...). # beadm destroy safe Are you sure you want to destroy 'safe'? This action cannot be undone (y/[n]): # bectl destroy safe # (deleted)
(In reply to vermaden from comment #18) I think we want to take consistency with other tools in the base system on your last point, though we should probably mention in the man page this divergence from historic beadm behavior. I'll draft up a patch for all of this and see if re@ is OK with it.
(In reply to Kyle Evans from comment #6) > libbe(3) and beadm(8) have been merged into head as of r337667. Was there a typo, or am I a little confused? With FreeBSD 12.0-ALPHA9 r339356 I have: - the manual page for bectl(8) (with its "… based on beadm …" line) - no manual page for beadm(8).
(In reply to Graham Perrin from comment #20) Typo indeed- the naming went from beadm(8) -> be(8) -> bectl(8), so I still interchange things in my fingers occasionally.