Solved What entries from bectl should be deleted and when to update the active session?

R

resilient294

Hello everyone, I have the following `bectl` list of entries that is growing with each entry I add before updating the system and packages.
  • Can I delete any entry without damaging the system?
  • Is it good practice to keep updating the active session with each entry I add? I left mine way back when I built the system.
  • Is there anything else that I can do better with bectl?
thank you!

Code: 
BE                                Active Mountpoint Space
14.2-RELEASE-p3_2025-07-21_131752 -      -          1.73G
14.2-RELEASE-p4_2025-08-11_113254 -      -          866M 
14.2-RELEASE-p5_2025-08-21_002348 -      -          1.63M
14.2-RELEASE_2025-04-25_201229    -      -          54.7M
14.3-RELEASE-p2_2025-08-21_002719 -      -          1.57M
14.3-RELEASE-p2_2025-10-02_115932 -      -          760K 
14.3-RELEASE-p4_2025-11-04_113851 -      -          688K 
14.3-RELEASE-p5_2025-12-16_120109 -      -          692K 
14.3-RELEASE-p6_2026-01-08_105926 -      -          648K 
14.3-RELEASE-p7_2026-01-28_111514 -      -          664K 
default                           NR     /          46.2G
20250425                          -      -          324K 
20250425-de                       -      -          19.0M
20250512                          -      -          344M 
20250517                          -      -          332M 
20250531                          -      -          209M 
20250908                          -      -          109M 
20250915                          -      -          117M 
20251002                          -      -          664K 
20251020                          -      -          293M 
20251104                          -      -          744K 
20251126                          -      -          323M 
20251216                          -      -          664K 
20260108                          -      -          624K 
20260128                          -      -          608K
 
resilient294 said:
Can I delete any entry without damaging the system?
Click to expand...
Look at the flags,
Code: 
 The Active field indicates
             whether the boot environment is active now (N); active on reboot
             (R); is used on next boot once (T); or combination of (NRT).
If an entry has NO flags, it can be safely deleted.
 
by default freebsd-update install creates a new BE that is the system before any updates are applied.
Lets say installation you take the installer defaults.
That gives you a BE named default, that is the version you installed. Lets say 14.2-RELEASE-p0.
Then you do freebsd-update to get to 14.2-RELEASE-p3|p4 etc up through 14.3-RELEASE-p8.
You wind up with the contents of the BE named default being 14.3-RELEASE-p8, and freebsd-update created all the other timestamped ones.

You can leave it at that or use bectl rename to change the name (your call, whatever is easier for you to remember).

But as SirDice says, any BE that does not have flags can be safely deleted.
 
By the way, you can destroy all boot environments (which are in fact ZFS snapshots), except the default, all at once, or a range of BE's.

See /usr/share/games/fortune/freebsd-tips:
Code: 
You can delete a range of ZFS snapshots (a-z) in multiple ways.
The following will delete d and all earlier snapshots:

zfs destroy mypool/data@%d

To delete d and all later snapshots:

zfs destroy mypool/data@d%

To delete all dataset snapshots:

zfs destroy mypool/data@%

To destroy a range of boot environments, use bectl list -a to check the BE's snapshots. After specifying the range, "dry-run" before destruction: zfs destroy -n.

I don't know if bectl(8) supports all or range destruction of BE's, nothing I tried worked.

Example of destroy-all-at-once:
Rich (BB code): 
 # bectl list
BE                                          Active Mountpoint Space Created
20250412                                    -      -          8K    2026-02-13 15:19
20250420                                    -      -          8K    2026-02-13 15:20
20250424                                    -      -          8K    2026-02-13 15:20
20250524                                    -      -          8K    2026-02-13 15:20
20250530                                    -      -          8K    2026-02-13 15:20
20250610                                    -      -          8K    2026-02-13 15:20
20250615                                    -      -          8K    2026-02-13 15:20
FreeBSD-14.3-RELEASE-p1_2026-02-13_15:21:57 -      -          180K  2026-02-13 15:21
FreeBSD-14.3-RELEASE-p1_2026-02-13_15:22:24 -      -          8K    2026-02-13 15:22
FreeBSD-14.3-RELEASE-p2_2026-02-13_15:22:27 -      -          8K    2026-02-13 15:22
FreeBSD-14.3-RELEASE-p2_2026-02-13_15:22:31 -      -          8K    2026-02-13 15:22
FreeBSD-14.3-RELEASE-p3_2026-02-13_15:22:34 -      -          8K    2026-02-13 15:22
FreeBSD-14.3-RELEASE-p4_2026-02-13_15:22:37 -      -          8K    2026-02-13 15:22
FreeBSD-14.3-RELEASE-p5_2026-02-13_15:22:41 -      -          8K    2026-02-13 15:22
default                                     NR     /          1.50G 2026-01-31 13:29


 # zfs list -t snap
NAME                                       USED  AVAIL  REFER  MOUNTPOINT
zroot/ROOT/default@2026-02-13-15:19:56-0     0B      -  1.50G  -
zroot/ROOT/default@2026-02-13-15:19:57-0     0B      -  1.50G  -
zroot/ROOT/default@2026-02-13-15:20:13-0     0B      -  1.50G  -
zroot/ROOT/default@2026-02-13-15:20:16-0     0B      -  1.50G  -
zroot/ROOT/default@2026-02-13-15:20:20-0     0B      -  1.50G  -
zroot/ROOT/default@2026-02-13-15:20:26-0     0B      -  1.50G  -
zroot/ROOT/default@2026-02-13-15:20:33-0     0B      -  1.50G  -
zroot/ROOT/default@2026-02-13-15:20:35-0     0B      -  1.50G  -
zroot/ROOT/default@2026-02-13-15:21:57-0   172K      -  1.50G  -
zroot/ROOT/default@2026-02-13-15:22:24-0     0B      -  1.50G  -
zroot/ROOT/default@2026-02-13-15:22:27-0     0B      -  1.50G  -
zroot/ROOT/default@2026-02-13-15:22:31-0     0B      -  1.50G  -
zroot/ROOT/default@2026-02-13-15:22:34-0     0B      -  1.50G  -
zroot/ROOT/default@2026-02-13-15:22:37-0     0B      -  1.50G  -
zroot/ROOT/default@2026-02-13-15:22:41-0     0B      -  1.50G  -


 # zfs destroy -vR zroot/ROOT/default@%
will destroy zroot/ROOT/default@2026-02-13-15:19:56-0
will destroy zroot/ROOT/default@2026-02-13-15:19:57-0
will destroy zroot/ROOT/default@2026-02-13-15:20:13-0
will destroy zroot/ROOT/default@2026-02-13-15:20:16-0
will destroy zroot/ROOT/default@2026-02-13-15:20:20-0
will destroy zroot/ROOT/default@2026-02-13-15:20:26-0
will destroy zroot/ROOT/default@2026-02-13-15:20:33-0
will destroy zroot/ROOT/default@2026-02-13-15:20:35-0
will destroy zroot/ROOT/default@2026-02-13-15:21:57-0
will destroy zroot/ROOT/default@2026-02-13-15:22:24-0
will destroy zroot/ROOT/default@2026-02-13-15:22:27-0
will destroy zroot/ROOT/default@2026-02-13-15:22:31-0
will destroy zroot/ROOT/default@2026-02-13-15:22:34-0
will destroy zroot/ROOT/default@2026-02-13-15:22:37-0
will destroy zroot/ROOT/default@2026-02-13-15:22:41-0
will reclaim 480K
will destroy zroot/ROOT/20250412
will destroy zroot/ROOT/20250420
will destroy zroot/ROOT/20250424
will destroy zroot/ROOT/20250524
will destroy zroot/ROOT/20250530
will destroy zroot/ROOT/20250610
will destroy zroot/ROOT/20250615
will destroy zroot/ROOT/FreeBSD-14.3-RELEASE-p1_2026-02-13_15:21:57
will destroy zroot/ROOT/FreeBSD-14.3-RELEASE-p1_2026-02-13_15:22:24
will destroy zroot/ROOT/FreeBSD-14.3-RELEASE-p2_2026-02-13_15:22:27
will destroy zroot/ROOT/FreeBSD-14.3-RELEASE-p2_2026-02-13_15:22:31
will destroy zroot/ROOT/FreeBSD-14.3-RELEASE-p3_2026-02-13_15:22:34
will destroy zroot/ROOT/FreeBSD-14.3-RELEASE-p4_2026-02-13_15:22:37
will destroy zroot/ROOT/FreeBSD-14.3-RELEASE-p5_2026-02-13_15:22:41

 # bectl list
BE      Active Mountpoint Space Created
default NR     /          1.50G 2026-01-31 13:29
 
T-Daemon said:
By the way, you can destroy all boot environments (which are in fact ZFS snapshots), except the default, all at once, or a range of BE's.
Click to expand...
I'm going to be picky here about use of the term "default". I think it's better to use the "having no flags" as SirDice says. This is part of the reason I have no BE named "default".

I don't know what would happing if you are in one BE (N), activate another one (R), then delete the one you just activated. Does bectl prevent this? Hopefully, but raw zfs destroy probably does not.
 
mer said:
I'm going to be picky here about use of the term "default". I think it's better to use the "having no flags" as SirDice says. This is part of the reason I have no BE named "default".
Click to expand...
Neither do I have a "default" named BE (on my production system). In order not to complicate matters for the OP by using terminology that may be unfamiliar to him, I used what is displayed by bectl(8) for NR.

mer said:
I don't know what would happing if you are in one BE (N), activate another one (R), then delete the one you just activated. Does bectl prevent this? Hopefully, but raw zfs destroy probably does not.
Click to expand...
bectl(8) won't prevent it, neither does zfs-destroy(8). The temporary activated BE (R) (while in the current active BE (N) ) would be destroyed.

If the temporary activated BE is booted into, neither bectl(8) nor zfs-destroy(8) won't be able to destroy it.

Note "snapshot is cloned":
Code: 
 # bectl activate -t test
Successfully activated boot environment test for next boot

 # shutdown -r now
 
 # bectl list
BE    Active Mountpoint Space Created
15p2  R      -          1.50G 2026-01-31 13:29
test  N      /          376K  2026-02-13 17:37
test1 -      -          8K    2026-02-13 17:37
 

# zfs destroy -vR zroot/ROOT/15p2@%
will destroy zroot/ROOT/15p2@2026-02-13-17:37:44-0
will destroy zroot/ROOT/15p2@2026-02-13-17:37:52-0
will reclaim 384K
will destroy zroot/ROOT/test
cannot unmount '/': unmount failed
will destroy zroot/ROOT/test1
cannot destroy snapshot zroot/ROOT/15p2@2026-02-13-17:37:44-0: snapshot is cloned

 # zfs get -r clones zroot/ROOT
NAME                                   PROPERTY  VALUE            SOURCE
zroot/ROOT                             clones    -                -
zroot/ROOT/15p2                        clones    -                -
zroot/ROOT/15p2@2026-02-13-17:37:44-0  clones    zroot/ROOT/test  -
zroot/ROOT/15p2@2026-02-13-17:37:52-0  clones    -                -
zroot/ROOT/test                        clones    -                -
 

 # bectl list
BE   Active Mountpoint Space Created
15p2 R      -          1.50G 2026-01-31 13:29
test N      /          444K  2026-02-13 17:37
 
T-Daemon said:
Neither do I have a "default" named BE (on my production system).
Click to expand...

In my original post, the `bectl` entry named 'default' is what I called my newly installed system before I started installing packages.

Is it advised to keep updating the active flags as I create new BE entries?

My usual practice is to leave the active flags where they currently are - when a created the system a year or so ago (this is a computer used for web dev and other office work), keep the last two entries from the last updates, and delete everything else. I was wondering if it makes any difference to move the active flag to ...the second to last entry? Like a protocol to follow to have a good working operating system.
 
resilient294 said:
Is it advised to keep updating the active flags as I create new BE entries?
Click to expand...
I'm assuming this means "you are booted into the the BE named default, then you bectl create a new BE, then do updates into the BE named default".

If that is correct, then the manually created BEs are "default before I do anything". In that case, just leave flags alone so "default" is activated.

"default" will always be your latest updates, your manually created BEs are your rollback or backup if something is broken in "default".
 
You must log in or register to reply here.
Back
Top