Bug 253445 - bectl: does not function in two-level zfs datasets
Summary: bectl: does not function in two-level zfs datasets
Status: In Progress
Alias: None
Product: Base System
Classification: Unclassified
Component: bin (show other bugs)
Version: 12.2-RELEASE
Hardware: Any Any
: --- Affects Only Me
Assignee: Kyle Evans
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2021-02-11 21:35 UTC by dougs@dawnsign.com
Modified: 2021-06-12 20:06 UTC (History)
4 users (show)

See Also:


Attachments
diff to allow the pool dataset to be the BE root when specified (1.09 KB, patch)
2021-02-11 23:31 UTC, Wes Maag
no flags Details | Diff

Note You need to log in before you can comment on or make changes to this bug.
Description dougs@dawnsign.com 2021-02-11 21:35:31 UTC
I used mfsbsd to set up default datasets. If using non-raid, by default, mfsbsd formats its zfs datasets for a single disk as follows:

Filesystem 1K-blocks Used Avail Capacity Mounted on
tank/root 302305222 9711156 292594065 3% /
devfs 1 1 0 100% /dev
tank/root/tmp 292594102 37 292594065 0% /tmp
tank/root/var 292924432 330366 292594065 0% /var

When I attempt to list bootable environments, it comes back empty.

[root@squid 11.Feb 12:20pm /usr]# bectl list
[root@squid 11.Feb 12:20pm /usr]#

bectl check does not return anything:

[root@squid 11.Feb 12:20pm /usr]# bectl check
[root@squid 11.Feb 12:20pm /usr]#

I would like to implement boot environments using two level datasets.

Is the three level datasets a requirement for using bectl?

See https://forums.freebsd.org/threads/boot-environments-with-non-standard-dataset-layout-and-bectl-beadm.74925/ for additional details.
Comment 1 Wes Maag 2021-02-11 22:12:05 UTC
(In reply to dougs@dawnsign.com from comment #0)

Out of curiosity, what happens if you specify the root as tank?

i.e bectl -r tank list?
Comment 2 dougs@dawnsign.com 2021-02-11 22:37:27 UTC
[root@squid 11.Feb 12:32pm /]# bectl -r tank list
[root@squid 11.Feb 2:36pm /]#
Comment 3 dougs@dawnsign.com 2021-02-11 22:44:26 UTC
Out of curiosity, I did this:

[root@squid 11.Feb 2:36pm /usr]# bectl -r tank/root list
BE  Active Mountpoint Space Created
tmp -      /tmp       58K   2021-02-06 13:49
var -      /var       336M  2021-02-06 13:49
[root@squid 11.Feb 2:37pm /usr]#
Comment 4 Wes Maag 2021-02-11 23:31:09 UTC
Created attachment 222379 [details]
diff to allow the pool dataset to be the BE root when specified
Comment 5 Wes Maag 2021-02-11 23:33:19 UTC
Yeah, libbe really wants there to be at least two levels. It checks for the existence of a '/' in the root name and errors out if it does not exist.

Attached is a diff that I scratched together which seems to work

works[wes]:/home/wes $ zfs list -r test                                                                                                                                                                                                 [16:27:06]
NAME         USED  AVAIL     REFER  MOUNTPOINT
test         246K   832M       24K  none
test/root1    24K   832M       24K  /tmp/bectl_test_75GY
test/root2    24K   832M       24K  /tmp/bectl_test_75GY

works[wes]:/home/wes $ bectl -r test list                                                                                                                                                                                               [16:16:30]
BE    Active Mountpoint Space Created
root1 -      -          24K   2021-02-11 15:46
root2 -      -          24K   2021-02-11 15:46
Comment 6 Kyle Evans freebsd_committer 2021-02-12 14:18:00 UTC
We're discussing this a bit out-of-band; in principle Wes's patch is fine, so we'll get this fixed pretty quickly.
Comment 7 dougs@dawnsign.com 2021-02-13 00:30:12 UTC
That's great news! How soon will it be before the changes are rolled out?
Comment 8 dougs@dawnsign.com 2021-05-31 22:21:33 UTC
It will be June 1st tomorrow. How soon can I expect this in the RELEASE version?
Comment 9 Robert Wing freebsd_committer 2021-06-03 20:00:17 UTC
(In reply to dougs@dawnsign.com from comment #8)

Have you tested the patch provided by Wes? Does it work for you?
Comment 10 dougs@dawnsign.com 2021-06-03 20:05:04 UTC
(In reply to Robert Wing from comment #9)
I'm afraid I do not know how to implement the change. I do not compile my sources/kernel at all-- I use freebsd-update to download/install binary files.

That said, if you could point me in the right direction, I could be persuaded to test! Is there a way I could drop a binary replacement file in place and test?
Comment 11 Wes Maag 2021-06-04 13:10:37 UTC
Hello everyone, 

At the time I replied, I was having issues logging in to reviews.f.o and didn't create a review for this. But that has been resolved and I added a review to hopefully grease the wheels a bit :)

review D30636
Comment 12 Robert Wing freebsd_committer 2021-06-05 00:08:44 UTC
(In reply to dougs@dawnsign.com from comment #10)

To dougs: Possibly, what version are you on? and/or output of `uname -a`?

To Wes: Thanks for posting a review - I'll give it a look over in the next few days.
Comment 13 dougs@dawnsign.com 2021-06-07 14:30:26 UTC
(In reply to Robert Wing from comment #12)

[root@squid 07.Jun 7:23am ~]# uname -a
FreeBSD squid.dawnsign.com 12.2-RELEASE-p7 FreeBSD 12.2-RELEASE-p7 GENERIC  amd64

Also:

[root@fornax 07.Jun 7:22am ~]# uname -a
FreeBSD fornax.dawnsign.com 13.0-RELEASE-p1 FreeBSD 13.0-RELEASE-p1 #0: Wed May 26 22:15:09 UTC 2021     root@amd64-builder.daemonology.net:/usr/obj/usr/src/amd64.amd64/sys/GENERIC  amd64
Comment 14 Robert Wing freebsd_committer 2021-06-12 20:06:49 UTC
(In reply to dougs@dawnsign.com from comment #13)

If you get around to it...try the following on your 13.0 machine and let us know if it works:


# curl https://people.freebsd.org/~rew/libbe-D30636.so --output libbe-D30636.so
# env LD_PRELOAD=/absolute/path/to/libbe-D30636.so /sbin/bectl -r tank list

The curl command is downloading a patched version of the libbe library. This patched libbe version uses Wes's patch found at https://reviews.freebsd.org/D30636

You must pass the absolute path of the patched libbe library to LD_PRELOAD.