Bug 230323 - Idea/Feature Request - include beadm in the base
Summary: Idea/Feature Request - include beadm in the base
Status: Closed FIXED
Alias: None
Product: Base System
Classification: Unclassified
Component: bin (show other bugs)
Version: CURRENT
Hardware: Any Any
: --- Affects Many People
Assignee: Mariusz Zaborski
URL: https://github.com/vermaden/beadm
Keywords:
Depends on:
Blocks:
 
Reported: 2018-08-03 12:03 UTC by vermaden
Modified: 2018-10-18 13:12 UTC (History)
4 users (show)

See Also:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description vermaden 2018-08-03 12:03:34 UTC
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.
Comment 1 Conrad Meyer freebsd_committer 2018-08-03 15:45:22 UTC
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.)
Comment 2 Kyle Evans freebsd_committer 2018-08-03 15:54:15 UTC
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/
Comment 3 Mariusz Zaborski freebsd_committer 2018-08-03 17:08:59 UTC
I would like to have something before 12.0.
Kyle do you thing that your work will be finished before it?
Comment 4 Kyle Evans freebsd_committer 2018-08-03 17:16:32 UTC
(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.
Comment 5 Kyle Evans freebsd_committer 2018-08-06 14:50:19 UTC
(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.
Comment 6 Kyle Evans freebsd_committer 2018-08-12 00:35:26 UTC
libbe(3) and beadm(8) have been merged into head as of r337667.
Comment 7 Mariusz Zaborski freebsd_committer 2018-08-17 12:00:19 UTC
So I guess we can close this bug.
Comment 8 vermaden 2018-08-17 14:52:43 UTC
(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.
Comment 9 Kyle Evans freebsd_committer 2018-08-17 14:56:36 UTC
(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.
Comment 10 vermaden 2018-08-17 15:51:31 UTC
(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 ;)
Comment 11 vermaden 2018-08-21 12:04:01 UTC
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.
Comment 12 Kyle Evans freebsd_committer 2018-08-21 13:57:12 UTC
(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)
Comment 13 Allan Jude freebsd_committer 2018-08-21 14:01:29 UTC
(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.
Comment 14 vermaden 2018-08-21 14:23:25 UTC
(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 :)
Comment 15 Kyle Evans freebsd_committer 2018-08-21 14:30:28 UTC
(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.
Comment 16 vermaden 2018-08-24 08:52:10 UTC
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
Comment 17 vermaden 2018-08-24 08:54:28 UTC
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
Comment 18 vermaden 2018-08-24 08:58:08 UTC
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)
Comment 19 Kyle Evans freebsd_committer 2018-08-24 14:00:36 UTC
(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.
Comment 20 Graham Perrin 2018-10-18 06:24:06 UTC
(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).
Comment 21 Kyle Evans freebsd_committer 2018-10-18 13:12:28 UTC
(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.