Reflections on boot environments.

Alain De Vos · Nov 13, 2021

I did my own scheme setting up zfs&zpool
ZT/ROOT 96.5G 161G 96K none
ZT/ROOT/default 96.5G 161G 43.8G legacy
ZT/ROOT/default/usr 31.1G 161G 96K none
ZT/ROOT/default/var 18.1G 161G 96K none
Can I use "Vermadens" boot environments or are i'm in for problems or not ? When can I expect problems?
I never dared to use boot environments, but when zfs/zpools upgrade to a newer version, it can sometimes be a good idea.
How do you configure booting i.e. the process of mounting root filesystem to use zfs vs openzfs one or the other,what's best and how ?
For me it spits out a few of errors but it does it job. But For howlong ?
My bios is stupid, so i don't use uefi, and the partion i use can not be too small. Bye the way is this part of handbook as it should?
A link to man page,

bectl(8)

www.freebsd.org

grahamperrin · Nov 14, 2021

~~bectl and associated use cases are missing from the FreeBSD Handbook.~~

Alain De Vos said:
How do you configure booting i.e. the process of mounting root filesystem to use zfs vs openzfs one or the other,what's best and how ?

If you use FreeBSD 12.2-⋯ or 12.3-⋯ you can install sysutils/openzfs. Automated installation of the kernel module will be followed by the package message about how to enable the ported software.

OpenZFS is integral to FreeBSD 13.0-RELEASE⋯.

I never dared to use boot environments, but when zfs/zpools upgrade to a newer version, it can sometimes be a good idea.

I can't comment on your custom scheme, but generally: you should be able to create (and activate then boot) a boot environment without hesitation.

I habitually create, activate then boot an environment before any pkg upgrade; and so on.

Hint: choose concise, descriptive names. A name beginning with the date i.e. 20211114 might be most useful.

mer · Nov 14, 2021

Boot environments use a fairly specific layout of datasets. A lot of "canmount = no" and/or "mountpoint = none" to get things correct.
Easiest way to see is do a fresh install, can simply be into a VM, then do a zpool history command. That gives you the what datasets are created, how they are created, their mount points and mount options.

The bectl command may have info missing from the handbook, but in use anytime you see "beadm" you can safely substitute "bectl". beadm is a port of the Solaris utility (shell script), bectl is the native FreeBSD command (binary executable).
I'm sure the docs team would accept or at least appreciate patches/updates to cover bectl.

Boot environments are a good thing in my opinion. It's "upgrading a system safely done right".
I typically use them when I am upgrading: freebsd-update gets a new BE. Simply upgrading packages, not so much, but you could.
Naming? Whatever makes sense to you. This is my naming convention. But you do what makes sense to you.


bectl list
BE                           Active Mountpoint Space Created
13.0-RELEASE-p2 -              -                  2.79G     2021-06-15 07:22
13.0-RELEASE-p3 NR          /                 14.6G     2021-07-08 08:27
default                     -             -                 5.59G      2019-12-06 07:34

grahamperrin · Nov 14, 2021

Oops!

mer said:
… "beadm" you can safely substitute …

– sorry. I forgot the obvious.

mer said:
… my naming convention. …

Mine (recently pruned):

Code:

% bectl list -c creation
BE                    Active Mountpoint Space Created
n250511-5f73b3338ee-c -      -          1.84M 2021-11-08 03:29
n250511-5f73b3338ee-d -      -          20.3M 2021-11-13 15:43
n250650-ef396441ceb-a NR     /          65.6G 2021-11-14 00:24
% uname -aKU
FreeBSD mowa219-gjp4-8570p-freebsd 14.0-CURRENT FreeBSD 14.0-CURRENT #115 main-n250650-ef396441ceb: Sat Nov 13 23:52:09 GMT 2021     root@mowa219-gjp4-8570p-freebsd:/usr/obj/usr/src/amd64.amd64/sys/GENERIC-NODEBUG  amd64 1400041 1400041
%

The same convention might be useful for users of STABLE.

I recommend concise etc. because of the constraints of FreeBSD's loader menu; see <https://forums.freebsd.org/posts/535243> NB disorder. Can be eased by a handwritten or printed list of boot environments; or always save the most recent list to a paste bin that can be viewed on a phone or whatever.

Date-stamped names might be particularly useful to Alain because he does so much experimentation with ports etc..

mer · Nov 14, 2021

grahamperrin said:
Date-stamped names might be particularly useful to Alain because he does so much experimentation with ports etc..

That is all the more reason to properly setup and use BE's (experimentation) and decide on a naming that makes sense to you. Another idea would be in each BE, after you are done modifying it create a README file in the root directory, that describes what you've changed. Since the root (and /usr/local if correctly setup) follow the BE, there should be no overlap and you can quickly see what you've changed.

grahamperrin · Apr 10, 2022

mer said:
… in use anytime you see "beadm" you can safely substitute "bectl". …

Looking ahead: the latest beadm (not yet in the ports collection) includes a feature that's not in bectl: reroot.

Add reroot feature. · vermaden/beadm@75f7f38

FreeBSD utility to manage Boot Environments on ZFS filesystems. - Add reroot feature. · vermaden/beadm@75f7f38

github.com

ZFS Boot Environments Revolutions | vermaden𝚟𝚎𝚛𝚖𝚊𝚍𝚎𝚗𝚟𝚎𝚛𝚖𝚊𝚍𝚎𝚗

Background, via <https://vermaden.wordpress.com/2021/09/06/valuable-news-2021-09-06/>: Using FreeBSD's re-root capability

mer · Apr 10, 2022

Yep that is a good feature, but anyone that has done embedded systems knows that zero downtime upgrades are tricky.
What's typically on the root filesystem besides the kernel? Let's see, /lib, /usr/lib, /usr/bin, /sbin, /bin off the top of my head.
I upgrade into a new BE that includes say an update to libc. What happens if I reroot into that new BE? I can see at the time of reroot applications have libc open (as shared library), various portions actually mapped into memory and "now what?" Do you forcefully stop all applications, map in the new libc and restart the applications? Or do you mark "libc needs to be rerooted" and only perform the operation when there are no users of libc active?
Either one would work, but depending on "what" it is, it may never be not in use.

Kernels. I prefer to know as soon as possible if a kernel is going to cause problems/crash, so personal preference is to reboot into the new kernel as soon as I can.

NOTE:
I am NOT saying this is a useless/bad idea. I can easily see cases where it is a very good thing. Perhaps the cases I'm talking about are minor corner cases that rarely happen, but anyone that has been in the business long enough knows that minor corner cases are the ones that blow up on a customer and cause the CEO to scream at you.

grahamperrin · Apr 10, 2022

Also, if shutdown(8) is not used to reboot: sometimes, DRM might be tricky. (Discussion elsewhere; to be followed up.)