Skip site navigation (1)Skip section navigation (2)
Date:      Tue, 26 May 2026 10:24:52 +0200 (CEST)
From:      Ronald Klop <ronald-lists@klop.ws>
To:        Takashi Shimizu <qqyr7xx9k@shirt.ocn.ne.jp>
Cc:        freebsd-stable@freebsd.org
Subject:   Re: Proposal: Improve BE naming convention in freebsd-update install
Message-ID:  <1676824497.1245.1779783892574@localhost>
In-Reply-To: <70da0c5b-c865-44e9-8c19-abb1cd779efe@shirt.ocn.ne.jp>

index | next in thread | previous in thread | raw e-mail

[-- Attachment #1 --]
 
Van: Takashi Shimizu <qqyr7xx9k@shirt.ocn.ne.jp>
Datum: zondag, 24 mei 2026 13:53
Aan: freebsd-stable@freebsd.org
Onderwerp: Proposal: Improve BE naming convention in freebsd-update install
> 
> Hi,
> 
> I'd like to propose an improvement to the Boot Environment naming convention used by freebsd-update.
> 
> Current behavior and problems
> 
> Here is a typical bectl list output after several freebsd-update runs:
> 
> BE                                Active Mountpoint Space   Created
> 15.0-RELEASE-p2_2026-02-11_220708 -      -          5.22G  2026-02-11 22:07
> 15.0-RELEASE-p4_2026-04-23_104906 -      -          2.55G  2026-04-23 10:49
> 15.0-RELEASE-p5_2026-04-23_103138 -      -          69.5M  2026-04-23 10:31
> 15.0-RELEASE-p6_2026-05-06_110219 -      -          579M   2026-05-06 11:02
> 15.0-RELEASE-p8_2026-05-21_183216 NR     /          31.2G  2026-05-21 18:32
> 15.0-RELEASE-p8_2026-05-24_153246 -      -          1.29M  2026-05-24 15:32
> 15.0-RELEASE_2026-02-01_103504    -      -          179M   2026-02-01 10:35
> default                           -      -          1.22G  2026-02-01 10:29
> This output raises several problems:
> 
> The name "default" is misleading. It suggests "the BE that boots by default" or "the latest running state", but in practice it is just the residue of the initial installation, with no NR flag. The name and its actual purpose are mismatched.
> 
> freebsd-update install updates the current BE in place, then saves a snapshot of the pre-update state with a new date-stamped name. As a result, the actual content of the current BE does not match its name. In the example above, 15.0-RELEASE-p8_2026-05-21_183216 has the NR flag and is the running system, but its actual content is 15.0-RELEASE-p9, installed by freebsd-update. The name says p8, but the system is running p9. This is highly misleading, especially when trying to recover from a failed reboot.
> 
> Furthermore, the snapshot taken just before the update, 15.0-RELEASE-p8_2026-05-24_153246, has a newer timestamp than the current BE. The BE with the newer date is actually the older state. If a reboot fails and the user needs to identify which BE to activate, the date-based names actively mislead them.
> 
> As upgrades accumulate, date-stamped BEs proliferate with no clear indication of which is current and which are fallbacks.
> 
> Proposal
> 
> Rename the initial installation BE from "default" to "original". This accurately reflects its purpose as a preserved baseline.
> 
> After each freebsd-update install, rename the current BE to "HEAD". HEAD always refers to the latest BE created automatically by freebsd-update. User-created BEs are outside the scope of this convention and should be managed by the user themselves, with names of their own choosing such as "RELEASE-p9-preRC1".
> 
> The result would be a bectl list that is immediately understandable:
> 
> BE                                Active Mountpoint Space   Created
> HEAD                              NR     /          31.2G   2026-05-24
> RELEASE-p9-preRC1                 -      -          1.5G    2026-05-24
> 15.0-RELEASE-p6_2026-05-06        -      -          579M    2026-05-06
> 15.0-RELEASE-p2_2026-02-11        -      -          5.22G   2026-02-11
> original                          -      -          1.22G   2026-02-01
> HEAD is always the latest state managed by freebsd-update. User-created BEs with meaningful names serve as fallbacks for specific purposes. "original" is preserved as a historical baseline.
> 
> This change would make the BE state self-explanatory, reduce confusion after failed upgrades, and lower the risk of users activating the wrong BE during recovery.
> 
> Note: As FreeBSD transitions from freebsd-update to pkgbase, it would be worth considering whether pkgbase will provide automatic BE creation and a clear naming convention from the start, rather than inheriting the same confusion.
> 
> Thanks for considering this.
> Takashi


Hi,

I've read the rest of the thread also but reply on this one as it keeps the context of your question.
Bectl does not tell the user how to name the "active" BE. You can see which is active by the NR parameters.

You probably activated 15.0-RELEASE-p8_2026-05-21_183216 yourself in the past and then it sticks with that name. Because that is the BE you choose.
If you want it to have another name, you can easily rename it yourself on your system.

bectl rename 15.0-RELEASE-p8_2026-05-21_183216 HEAD

After the next run of freebsd-update you will have a new timestamped BE, but the active and updated one will still be named HEAD. 🥳

NB: Renaming a BE can give issues when using zfs send | zfs receive to a backup system. As the names on the backup didn't change, the ZFS filesystems+snapshots on the backup are out of sync now.

Regards,
Ronald.
 
[-- Attachment #2 --]
<html><head></head><body>&nbsp;
<p><strong>Van:</strong> Takashi Shimizu &lt;qqyr7xx9k@shirt.ocn.ne.jp&gt;<br>
<strong>Datum:</strong> zondag, 24 mei 2026 13:53<br>
<strong>Aan:</strong> freebsd-stable@freebsd.org<br>
<strong>Onderwerp:</strong> Proposal: Improve BE naming convention in freebsd-update install</p>

<blockquote style="padding-right: 0px; padding-left: 5px; margin-left: 5px; border-left: #000000 2px solid; margin-right: 0px">
<div class="MessageRFC822Viewer" id="P">
<div class="MultipartAlternativeViewer">
<div class="TextHTMLViewer" id="P.P.P">
<p>Hi,</p>

<p>I'd like to propose an improvement to the Boot Environment naming convention used by freebsd-update.</p>

<p><strong>Current behavior and problems</strong></p>

<p>Here is a typical bectl list output after several freebsd-update runs:</p>

<pre><code>BE                                Active Mountpoint Space   Created
15.0-RELEASE-p2_2026-02-11_220708 -      -          5.22G  2026-02-11 22:07
15.0-RELEASE-p4_2026-04-23_104906 -      -          2.55G  2026-04-23 10:49
15.0-RELEASE-p5_2026-04-23_103138 -      -          69.5M  2026-04-23 10:31
15.0-RELEASE-p6_2026-05-06_110219 -      -          579M   2026-05-06 11:02
15.0-RELEASE-p8_2026-05-21_183216 NR     /          31.2G  2026-05-21 18:32
15.0-RELEASE-p8_2026-05-24_153246 -      -          1.29M  2026-05-24 15:32
15.0-RELEASE_2026-02-01_103504    -      -          179M   2026-02-01 10:35
default                           -      -          1.22G  2026-02-01 10:29
</code></pre>

<p>This output raises several problems:</p>

<ol>
	<li>
	<p>The name "default" is misleading. It suggests "the BE that boots by default" or "the latest running state", but in practice it is just the residue of the initial installation, with no NR flag. The name and its actual purpose are mismatched.</p>
	</li>
	<li>
	<p>freebsd-update install updates the current BE in place, then saves a snapshot of the pre-update state with a new date-stamped name. As a result, the actual content of the current BE does not match its name. In the example above, 15.0-RELEASE-p8_2026-05-21_183216 has the NR flag and is the running system, but its actual content is 15.0-RELEASE-p9, installed by freebsd-update. The name says p8, but the system is running p9. This is highly misleading, especially when trying to recover from a failed reboot.</p>
	</li>
	<li>
	<p>Furthermore, the snapshot taken just before the update, 15.0-RELEASE-p8_2026-05-24_153246, has a newer timestamp than the current BE. The BE with the newer date is actually the older state. If a reboot fails and the user needs to identify which BE to activate, the date-based names actively mislead them.</p>
	</li>
	<li>
	<p>As upgrades accumulate, date-stamped BEs proliferate with no clear indication of which is current and which are fallbacks.</p>
	</li>
</ol>

<p><strong>Proposal</strong></p>

<ul>
	<li>
	<p>Rename the initial installation BE from "default" to "original". This accurately reflects its purpose as a preserved baseline.</p>
	</li>
	<li>
	<p>After each freebsd-update install, rename the current BE to "HEAD". HEAD always refers to the latest BE created automatically by freebsd-update. User-created BEs are outside the scope of this convention and should be managed by the user themselves, with names of their own choosing such as "RELEASE-p9-preRC1".</p>
	</li>
</ul>

<p>The result would be a bectl list that is immediately understandable:</p>

<pre><code>BE                                Active Mountpoint Space   Created
HEAD                              NR     /          31.2G   2026-05-24
RELEASE-p9-preRC1                 -      -          1.5G    2026-05-24
15.0-RELEASE-p6_2026-05-06        -      -          579M    2026-05-06
15.0-RELEASE-p2_2026-02-11        -      -          5.22G   2026-02-11
original                          -      -          1.22G   2026-02-01
</code></pre>

<p>HEAD is always the latest state managed by freebsd-update. User-created BEs with meaningful names serve as fallbacks for specific purposes. "original" is preserved as a historical baseline.</p>

<p>This change would make the BE state self-explanatory, reduce confusion after failed upgrades, and lower the risk of users activating the wrong BE during recovery.</p>

<p>Note: As FreeBSD transitions from freebsd-update to pkgbase, it would be worth considering whether pkgbase will provide automatic BE creation and a clear naming convention from the start, rather than inheriting the same confusion.</p>

<p>Thanks for considering this.</p>
Takashi</div>
</div>
</div>
</blockquote>
<br>
<br>
<span style="font-family:verdana,geneva,sans-serif;">Hi,<br>
<br>
I've read the rest of the thread also but reply on this one as it keeps the context of your question.<br>
Bectl does not tell the user how to name the "active" BE. You can see which is active by the&nbsp;<code>NR</code> parameters.<br>
<br>
You probably activated <code>15.0-RELEASE-p8_2026-05-21_183216</code> yourself in the past and then it sticks with that name. Because that is the BE you choose.<br>
If you want it to have another name, you can easily rename it yourself on your system.<br>
<br>
<code>bectl rename 15.0-RELEASE-p8_2026-05-21_183216&nbsp;HEAD</code><br>
<br>
After the next run of freebsd-update you will have a new timestamped BE, but the active and updated one will still be named HEAD. 🥳<br>
<br>
NB: Renaming a BE can give issues when using zfs send | zfs receive to a backup system. As the names on the backup didn't change, the ZFS filesystems+snapshots on the backup are out of sync now.<br>
<br>
Regards,<br>
Ronald.</span><br>
&nbsp;</body></html>
home | help

Want to link to this message? Use this
URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?1676824497.1245.1779783892574>