This makes the be_exists behavior match the comments that assert that we've
already checked that the dataset derived from the BE name is set to mount at
/.
Other changes of note:
- bectl_list sees another change; changing mountpoint based on mount status
turns out to be a bad idea, so instead make the mounted property of the
returned nvlist the path that it's mounted at
- Always return the "mountpoint" property in "mountpoint" if it's ste
Loader is still relied upon at the beginning of libbe to specify the be
root, but we can derive from that the primary zpool and any vdevs that we
need to set nextboot bits on.
This lets me successfully `bectl activate -t test`, but UEFI loader doesn't
quite yet understand so it's effectively defunct.
be_get_dataset_snapshots has been added to libbe(3), effectively returning
the same information as be_get_bootenv_props but for snapshots of the given
dataset. The assumption is that one will have the BE dataset name before
wanting to grab snapshots.
This also accomplishes the following:
- Proxy through zfs_nicenum as be_nicenum, because it looks better than
humanize_number and would presumably be useful to other libbe consumers.
- Rename be_get_snapshot_props to be_get_dataset_props, make it more useful
At a bare minimum, this function will return 0 if a BE is mounted at the
given path or non-zero otherwise. If the optional 'details' nvlist is
supplied, it is filled with an nvpair containing just the information about
the BE mounted at the path. This nvpair is structured just as it is for
be_get_bootenv_props, except limited to just the single mount point.
Based on the idea that we shouldn't have all-new library and utility going
into base that need WARNS=1...
- Decent amount of constification
- Lots of parentheses
- Minor other nits
For the moment, this is a primitive nvlist dump of what we get back from
be_get_bootenv_props as a proof-of-concept and to make sure that we're
getting back the kind of information we want to see from list.
This makes us more resilient to a rename of the bootfs, but still wouldn't
withstand pool renames or guid renames. More importantly, this allows `bectl
create <foo>` work out of the box to create a boot environment based on the
currently booted one.
- Rename 'active' to 'rootfs', which is used in other places to describe the
currently booted (or about to be booted) BE.
- Add 'bootfs', which indicates the next boot environment to be booted. This
is pulled from the BOOTFS zpool property.
- Go ahead and keep an open handle to the active zpool. We might need to
enumerate datasets, get properties, and set properties (e.g. bootfs)
throughout other libbe bits, and a single handle isn't overly expensive.
