Forum: Too Lazy BBS

Proposal: Improve BE naming convention in freebsd-update install

From Takashi Shimizu@qqyr7xx9k@shirt.ocn.ne.jp to muc.lists.freebsd.stable on Sun May 24 20:53:59 2026

From Newsgroup: muc.lists.freebsd.stable

This is a multi-part message in MIME format. --------------yhPw1Vg0xH1fOWcBQ0GpAk2U
Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit

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:

1.

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.

2.

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.

3.

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.

4.

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
--------------yhPw1Vg0xH1fOWcBQ0GpAk2U
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: 7bit

<!DOCTYPE html>
<html>
<head>
<meta http-equiv="content-type" content="text/html; charset=UTF-8">
</head>
<body>
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:
<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>
This output raises several problems:
<ol>
<li>
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.
</li>
<li>
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.
</li>
<li>
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.
</li>
<li>
As upgrades accumulate, date-stamped BEs proliferate with no
clear indication of which is current and which are fallbacks.
</li>
</ol>
Proposal
<ul>
<li>
Rename the initial installation BE from "default" to
"original". This accurately reflects its purpose as a
preserved baseline.
</li>
<li>
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".
</li>
</ul>
The result would be a bectl list that is immediately
understandable:
<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>
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
</body>
</html>

--------------yhPw1Vg0xH1fOWcBQ0GpAk2U--

--
Posted automagically by a mail2news gateway at muc.de e.V.
Please direct questions, flames, donations, etc. to news-admin@muc.de
--- Synchronet 3.22a-Linux NewsLink 1.2

From Takashi Shimizu@qqyr7xx9k@shirt.ocn.ne.jp to muc.lists.freebsd.stable on Mon May 25 15:41:44 2026

From Newsgroup: muc.lists.freebsd.stable

This is a multi-part message in MIME format. --------------YBct0J9MrA7AwIfOeGt0PaUI
Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit

Thank you for your thoughtful response.

I think there was a misunderstanding about the core of my proposal. I
was not suggesting a naming convention for users to follow manually. The proposal is that freebsd-update itself should automatically rename the
current BE to "HEAD" after each install operation.

To be more explicit:

* When freebsd-update install completes, it renames the current BE to
"HEAD" automatically.
* The next time freebsd-update install runs, it again renames the
current BE to "HEAD", overwriting the previous name.
* This guarantees that "HEAD" always refers to the latest state
managed by freebsd-update, without any user intervention.

This addresses your concern about name shifting. The shifting is done by freebsd-update itself, not by the user.

Regarding your point that "HEAD" does not describe what is in the BE:
that is intentional. The pre-update snapshot retains the version-stamped
name such as 15.0-RELEASE-p8_2026-05-24, which does describe its
contents. "HEAD" is not meant to describe contents but to indicate
position: it is always the tip of the freebsd-update managed state,
analogous to HEAD in version control.

I agree that "original" has the same weakness in not describing its
contents. Naming it after the installed version, such as "15.0-RELEASE",
would be more informative.

Takashi

--------------YBct0J9MrA7AwIfOeGt0PaUI
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: 7bit

<!DOCTYPE html>
<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=UTF-8">
</head>
<body>
Thank
you for your thoughtful response.
I
think there was a misunderstanding about the core of my proposal.
I was not suggesting a naming convention for users to follow
manually. The proposal is that freebsd-update itself should
automatically rename the current BE to "HEAD" after each install
operation.
To
be more explicit:
<ul
class="[li_&]:mb-0 [li_&]:mt-1 [li_&]:gap-1 [&:not(:last-child)_ul]:pb-1 [&:not(:last-child)_ol]:pb-1 list-disc flex flex-col gap-1 pl-8 mb-3">
<li
class="font-claude-response-body whitespace-normal break-words pl-2">When
freebsd-update install completes, it renames the current BE to
"HEAD" automatically.</li>
<li
class="font-claude-response-body whitespace-normal break-words pl-2">The
next time freebsd-update install runs, it again renames the
current BE to "HEAD", overwriting the previous name.</li>
<li
class="font-claude-response-body whitespace-normal break-words pl-2">This
guarantees that "HEAD" always refers to the latest state managed
by freebsd-update, without any user intervention.</li>
</ul>
This
addresses your concern about name shifting. The shifting is done
by freebsd-update itself, not by the user.
Regarding
your point that "HEAD" does not describe what is in the BE: that
is intentional. The pre-update snapshot retains the
version-stamped name such as 15.0-RELEASE-p8_2026-05-24, which
does describe its contents. "HEAD" is not meant to describe
contents but to indicate position: it is always the tip of the
freebsd-update managed state, analogous to HEAD in version
control.
I
agree that "original" has the same weakness in not describing its
contents. Naming it after the installed version, such as
"15.0-RELEASE", would be more informative.
Takashi
</body>
</html>

--------------YBct0J9MrA7AwIfOeGt0PaUI--

--
Posted automagically by a mail2news gateway at muc.de e.V.
Please direct questions, flames, donations, etc. to news-admin@muc.de
--- Synchronet 3.22a-Linux NewsLink 1.2

From Tuomo Latto@djv@iki.fi to muc.lists.freebsd.stable on Mon May 25 12:14:21 2026

From Newsgroup: muc.lists.freebsd.stable

On 25 May 2026 9.41.44 GMT+03:00, Takashi Shimizu <qqyr7xx9k@shirt.ocn.ne.jp> wrote:

I think there was a misunderstanding about the core of my proposal. I was not suggesting a naming convention for users to follow manually. The proposal is that freebsd-update itself should automatically rename the current BE to "HEAD" after each install operation.

To be more explicit:

* When freebsd-update install completes, it renames the current BE to
"HEAD" automatically.
* The next time freebsd-update install runs, it again renames the
current BE to "HEAD", overwriting the previous name.
* This guarantees that "HEAD" always refers to the latest state
managed by freebsd-update, without any user intervention.

This addresses your concern about name shifting. The shifting is done by freebsd-update itself, not by the user.

Regarding your point that "HEAD" does not describe what is in the BE: that is intentional. The pre-update snapshot retains the version-stamped name such as 15.0-RELEASE-p8_2026-05-24, which does describe its contents. "HEAD" is not meant to describe contents but to indicate position: it is always the tip of the freebsd-update managed state, analogous to HEAD in version control.

I agree that "original" has the same weakness in not describing its contents. Naming it after the installed version, such as "15.0-RELEASE", would be more informative.

As someone who does not use BEs and doesn't know very much about them,
I have some thoughts. So, take them for what they're worth.
HEAD is not a good name because you have to explain it. It also has traditionally
referred to sources and I don't think introducing it somewhere else is a good idea,
because that usage is distinct enough to cause confusion, especially since the other
suggested names refer to source versions.
If the idea is that it is the latest update and that we generally boot that latest version
except in some specific circumstances, the word "default" does rather come to mind.
Of course, that word by itself is not very descriptive beyond that.
Therefore, it would make sense to use "<Freebsd version description> (default)" instead,
where the version would be as you describe. You could even suggest version naming
conventions for manual usage such as "15-STABLE_<source timestamp>" or something.
Using " (default)" would mean you'd have to update the names so that it only exists
in one of them, which isn't that different from "HEAD". Although, if there actually is
a separate mechanism for a boot default, even if it's just picking the one that was used
the last time, that word simply won't do as you could have a different boot default
from the one named "default" and always moving that tag around would defeat the purpose
of having it.
Instead, you could do " (latest)" but, if you run forks or several branches, that word
could either be confusing OR a very good choice, because then each branch could have
that tag to represent their "head". In that case, you'd only remove it from the name,
if the version you were updating from had that tag and you were using the same version/branch name, so to speak. You'd (almost) always add it.
The first install being simply called "original" is almost as bad as calling the "HEAD"
simply "default". It would make more sense to have the version description there too.
I could see other words being used as tags there too, such as "initial" and "first", perhaps
maybe "original install", "initial install", and so on. The exact choice doesn't matter as
long as it is something you don't have think about at all in order to understand, which
is why that second word might be a useful addition.
So, I might be misunderstanding something here but maybe you could have
a pathological, likely non-realistic, example like the following, sorted by newest to oldest,
which may not be the best choice here, where someone would have started from
a release install, tracked 14-stable, went with 14.0 patchlevels for a while, upgraded to 14.1,
then went back to tracking 14-stable, and then upgrading to 15.0 release and also tracking
16-CURRENT simultaneously.
They'd have several concurrent versions installed, which may or may not make sense.
It would be messy to do this, I guess, but, importantly, the list is still somewhat legible
and there's some sense of what is what and the "head" of each branch is marked: "16-CURRENT_<ts3> (latest)"
"16-CURRENT_<ts2>"
"15.0-RELEASE-p8 (latest)"
"15.0-RELEASE-p7"
"16-CURRENT_<ts1>"
"15.0-RELEASE-p6"
"14-STABLE_<ts9> (latest)"
"14-STABLE_<ts8>"
"14-STABLE_<ts7>"
"14-STABLE_<ts6> xxbug test patch 2"
"14-STABLE_<ts5> xxbug test patch 1"
"14-STABLE_<ts4>"
"14-STABLE_<ts3>"
"14.1-RELEASE-p1 (latest)"
"14.1-RELEASE"
"14.0-RELEASE-p6 (latest)"
"14-STABLE_<ts2>"
"14-STABLE_<ts1>"
"14.0-RELEASE (initial install)"
You might not want to do this naming by hand but, if all the tools (overridably)
standardised the format, you could also create the facility (switches, UI fields)
to easily add some descriptions ("xxbug [...]") in names for e.g. testing purposes.
So, for what it's worth.
--
Tuomo
--
Posted automagically by a mail2news gateway at muc.de e.V.
Please direct questions, flames, donations, etc. to news-admin@muc.de
--- Synchronet 3.22a-Linux NewsLink 1.2

From Takashi Shimizu@qqyr7xx9k@shirt.ocn.ne.jp to muc.lists.freebsd.stable on Mon May 25 18:39:46 2026

From Newsgroup: muc.lists.freebsd.stable

This is a multi-part message in MIME format. --------------rqdyXTaF2dyPlF8MdkHDNErq
Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit

On 5/25/26 18:14, Tuomo Latto wrote:

As someone who does not use BEs and doesn't know very much about them,
I have some thoughts. So, take them for what they're worth.

HEAD is not a good name because you have to explain it. It also has traditionally
referred to sources and I don't think introducing it somewhere else is a good idea,
because that usage is distinct enough to cause confusion, especially since the other
suggested names refer to source versions.

If the idea is that it is the latest update and that we generally boot that latest version
except in some specific circumstances, the word "default" does rather come to mind.
Of course, that word by itself is not very descriptive beyond that. Therefore, it would make sense to use "<Freebsd version description> (default)" instead,
where the version would be as you describe. You could even suggest version naming
conventions for manual usage such as "15-STABLE_<source timestamp>" or something.

Using " (default)" would mean you'd have to update the names so that it only exists
in one of them, which isn't that different from "HEAD". Although, if there actually is
a separate mechanism for a boot default, even if it's just picking the one that was used
the last time, that word simply won't do as you could have a different boot default
from the one named "default" and always moving that tag around would defeat the purpose
of having it.

Instead, you could do " (latest)" but, if you run forks or several branches, that word
could either be confusing OR a very good choice, because then each branch could have
that tag to represent their "head". In that case, you'd only remove it from the name,
if the version you were updating from had that tag and you were using the same
version/branch name, so to speak. You'd (almost) always add it.

The first install being simply called "original" is almost as bad as calling the "HEAD"
simply "default". It would make more sense to have the version description there too.
I could see other words being used as tags there too, such as "initial" and "first", perhaps
maybe "original install", "initial install", and so on. The exact choice doesn't matter as
long as it is something you don't have think about at all in order to understand, which
is why that second word might be a useful addition.

So, I might be misunderstanding something here but maybe you could have
a pathological, likely non-realistic, example like the following, sorted by newest to oldest,
which may not be the best choice here, where someone would have started from a release install, tracked 14-stable, went with 14.0 patchlevels for a while, upgraded to 14.1,
then went back to tracking 14-stable, and then upgrading to 15.0 release and also tracking
16-CURRENT simultaneously.
They'd have several concurrent versions installed, which may or may not make sense.
It would be messy to do this, I guess, but, importantly, the list is still somewhat legible
and there's some sense of what is what and the "head" of each branch is marked:
"16-CURRENT_<ts3> (latest)"
"16-CURRENT_<ts2>"
"15.0-RELEASE-p8 (latest)"
"15.0-RELEASE-p7"
"16-CURRENT_<ts1>"
"15.0-RELEASE-p6"
"14-STABLE_<ts9> (latest)"
"14-STABLE_<ts8>"
"14-STABLE_<ts7>"
"14-STABLE_<ts6> xxbug test patch 2"
"14-STABLE_<ts5> xxbug test patch 1"
"14-STABLE_<ts4>"
"14-STABLE_<ts3>"
"14.1-RELEASE-p1 (latest)"
"14.1-RELEASE"
"14.0-RELEASE-p6 (latest)"
"14-STABLE_<ts2>"
"14-STABLE_<ts1>"
"14.0-RELEASE (initial install)"

You might not want to do this naming by hand but, if all the tools (overridably)
standardised the format, you could also create the facility (switches, UI fields)
to easily add some descriptions ("xxbug [...]") in names for e.g. testing purposes.

So, for what it's worth.

Thank you for the thoughtful suggestion.

I agree that "(latest)" is more self-explanatory than "HEAD" and I am
happy to adopt that.

However, I would like to keep the scope simple. Managing multiple
concurrent branches is something only experienced users would do, and
they are capable of managing their own BE names. Introducing logic to
handle multiple "(latest)" tags across branches would add complexity and potential bugs to freebsd-update.

My proposal is therefore limited to the simple case: freebsd-update
marks only the BE it last updated as "(latest)". Nothing more.

I also like "initial install" as a tag for the first BE. It is
immediately understandable without any explanation.

Takashi

--------------rqdyXTaF2dyPlF8MdkHDNErq
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: 7bit

<!DOCTYPE html>
<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=UTF-8">
</head>
<body>
 

<div class="moz-cite-prefix">On 5/25/26 18:14, Tuomo Latto wrote:</div>
<blockquote type="cite"
cite="mid:35C0A0DA-DEE3-49DD-81E3-E71E56190A3A@iki.fi">
<pre wrap="" class="moz-quote-pre">
As someone who does not use BEs and doesn't know very much about them,
I have some thoughts. So, take them for what they're worth.

HEAD is not a good name because you have to explain it. It also has traditionally
referred to sources and I don't think introducing it somewhere else is a good idea,
because that usage is distinct enough to cause confusion, especially since the other
suggested names refer to source versions.

If the idea is that it is the latest update and that we generally boot that latest version
except in some specific circumstances, the word "default" does rather come to mind.
Of course, that word by itself is not very descriptive beyond that.
Therefore, it would make sense to use "<Freebsd version description> (default)" instead,
where the version would be as you describe. You could even suggest version naming
conventions for manual usage such as "15-STABLE_<source timestamp>" or something.

Using " (default)" would mean you'd have to update the names so that it only exists
in one of them, which isn't that different from "HEAD". Although, if there actually is
a separate mechanism for a boot default, even if it's just picking the one that was used
the last time, that word simply won't do as you could have a different boot default
from the one named "default" and always moving that tag around would defeat the purpose
of having it.

Instead, you could do " (latest)" but, if you run forks or several branches, that word
could either be confusing OR a very good choice, because then each branch could have
that tag to represent their "head". In that case, you'd only remove it from the name,
if the version you were updating from had that tag and you were using the same version/branch name, so to speak. You'd (almost) always add it.

The first install being simply called "original" is almost as bad as calling the "HEAD"
simply "default". It would make more sense to have the version description there too.
I could see other words being used as tags there too, such as "initial" and "first", perhaps
maybe "original install", "initial install", and so on. The exact choice doesn't matter as
long as it is something you don't have think about at all in order to understand, which
is why that second word might be a useful addition.

So, I might be misunderstanding something here but maybe you could have
a pathological, likely non-realistic, example like the following, sorted by newest to oldest,
which may not be the best choice here, where someone would have started from
a release install, tracked 14-stable, went with 14.0 patchlevels for a while, upgraded to 14.1,
then went back to tracking 14-stable, and then upgrading to 15.0 release and also tracking
16-CURRENT simultaneously.
They'd have several concurrent versions installed, which may or may not make sense.
It would be messy to do this, I guess, but, importantly, the list is still somewhat legible
and there's some sense of what is what and the "head" of each branch is marked: "16-CURRENT_<ts3> (latest)"
"16-CURRENT_<ts2>"
"15.0-RELEASE-p8 (latest)"
"15.0-RELEASE-p7"
"16-CURRENT_<ts1>"
"15.0-RELEASE-p6"
"14-STABLE_<ts9> (latest)"
"14-STABLE_<ts8>"
"14-STABLE_<ts7>"
"14-STABLE_<ts6> xxbug test patch 2"
"14-STABLE_<ts5> xxbug test patch 1"
"14-STABLE_<ts4>"
"14-STABLE_<ts3>"
"14.1-RELEASE-p1 (latest)"
"14.1-RELEASE"
"14.0-RELEASE-p6 (latest)"
"14-STABLE_<ts2>"
"14-STABLE_<ts1>"
"14.0-RELEASE (initial install)"

You might not want to do this naming by hand but, if all the tools (overridably)
standardised the format, you could also create the facility (switches, UI fields)
to easily add some descriptions ("xxbug [...]") in names for e.g. testing purposes.

So, for what it's worth.

</pre>
</blockquote>
 
Thank
you for the thoughtful suggestion.
I
agree that "(latest)" is more self-explanatory than "HEAD" and I
am happy to adopt that.
However,
I would like to keep the scope simple. Managing multiple
concurrent branches is something only experienced users would do,
and they are capable of managing their own BE names. Introducing
logic to handle multiple "(latest)" tags across branches would add
complexity and potential bugs to freebsd-update.
My
proposal is therefore limited to the simple case: freebsd-update
marks only the BE it last updated as "(latest)". Nothing more.
I
also like "initial install" as a tag for the first BE. It is
immediately understandable without any explanation.
Takashi
</body>
</html>

--------------rqdyXTaF2dyPlF8MdkHDNErq--

--
Posted automagically by a mail2news gateway at muc.de e.V.
Please direct questions, flames, donations, etc. to news-admin@muc.de
--- Synchronet 3.22a-Linux NewsLink 1.2

From Ronald Klop@ronald-lists@klop.ws to muc.lists.freebsd.stable on Tue May 26 10:24:52 2026

From Newsgroup: muc.lists.freebsd.stable

------=_Part_1244_1356603490.1779783892407
Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: quoted-printable

=20
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 >=20

Hi,
=20
I'd like to propose an improvement to the Boot Environment naming convent=

ion used by freebsd-update.

=20
Current behavior and problems
=20
Here is a typical bectl list output after several freebsd-update runs:
=20
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:
=20
The name "default" is misleading. It suggests "the BE that boots by defau=

lt" or "the latest running state", but in practice it is just the residue o=
f the initial installation, with no NR flag. The name and its actual purpos=
e are mismatched.

=20
freebsd-update install updates the current BE in place, then saves a snap=

shot 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 a= bove, 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-upd= ate. The name says p8, but the system is running p9. This is highly mislead= ing, especially when trying to recover from a failed reboot.

=20
Furthermore, the snapshot taken just before the update, 15.0-RELEASE-p8_2=

026-05-24_153246, has a newer timestamp than the current BE. The BE with th=
e newer date is actually the older state. If a reboot fails and the user ne= eds to identify which BE to activate, the date-based names actively mislead=
them.

=20
As upgrades accumulate, date-stamped BEs proliferate with no clear indica=

tion of which is current and which are fallbacks.

=20
Proposal
=20
Rename the initial installation BE from "default" to "original". This acc=

urately reflects its purpose as a preserved baseline.

=20
After each freebsd-update install, rename the current BE to "HEAD". HEAD =

always refers to the latest BE created automatically by freebsd-update. Use= r-created BEs are outside the scope of this convention and should be manage=
d by the user themselves, with names of their own choosing such as "RELEASE= -p9-preRC1".

=20
The result would be a bectl list that is immediately understandable:
=20
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 B=

Es with meaningful names serve as fallbacks for specific purposes. "origina=
l" is preserved as a historical baseline.

=20
This change would make the BE state self-explanatory, reduce confusion af=

ter failed upgrades, and lower the risk of users activating the wrong BE du= ring recovery.

=20
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 con= fusion.

=20
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 pa=
st 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 y= our 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, bu=
t the active and updated one will still be named HEAD. =F0=9F=A5=B3

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

Regards,
Ronald.
=20
------=_Part_1244_1356603490.1779783892407
Content-Type: text/html; charset=utf-8
Content-Transfer-Encoding: quoted-printable

<html><head></head><body> 
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 freeb= sd-update install

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

I'd like to propose an improvement to the Boot Environment naming conven= tion used by freebsd-update.

Current behavior and problems

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

<pre><code>BE Active Mountpoint Space Crea= ted
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>

This output raises several problems:

=09<li>
=09The name "default" is misleading. It suggests "the BE that boots by d= efault" or "the latest running state", but in practice it is just the resid=
ue of the initial installation, with no NR flag. The name and its actual pu= rpose are mismatched.
=09</li>
=09<li>
=09freebsd-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 examp=
le above, 15.0-RELEASE-p8_2026-05-21_183216 has the NR flag and is the runn= ing 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 mis= leading, especially when trying to recover from a failed reboot.
=09</li>
=09<li>
=09Furthermore, 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 wit=
h the newer date is actually the older state. If a reboot fails and the use=
r needs to identify which BE to activate, the date-based names actively mis= lead them.
=09</li>
=09<li>
=09As upgrades accumulate, date-stamped BEs proliferate with no clear in= dication of which is current and which are fallbacks.
=09</li>
</ol>

Proposal

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

The result would be a bectl list that is immediately understandable:

<pre><code>BE Active Mountpoint Space Crea= ted
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>

HEAD is always the latest state managed by freebsd-update. User-created = BEs with meaningful names serve as fallbacks for specific purposes. "origin= al" is preserved as a historical baseline.

This change would make the BE state self-explanatory, reduce confusion a= fter failed upgrades, and lower the risk of users activating the wrong BE d= uring 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 co= nfusion.

Thanks for considering this.
Takashi</div>
</div>
</div>
</blockquote>

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 <code>NR</code> parameters. 

You probably activated <code>15.0-RELEASE-p8_2026-05-21_183216</code> yours= elf in the past and then it sticks with that name. Because that is the BE y=
ou choose. 
If you want it to have another name, you can easily rename it yourself on y= our system. 

<code>bectl rename 15.0-RELEASE-p8_2026-05-21_183216 HEAD</code> 

After the next run of freebsd-update you will have a new timestamped BE, bu=
t the active and updated one will still be named HEAD. =F0=9F=A5=B3 

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

Regards, 
Ronald. 
 </body></html>
------=_Part_1244_1356603490.1779783892407--

--
Posted automagically by a mail2news gateway at muc.de e.V.
Please direct questions, flames, donations, etc. to news-admin@muc.de
--- Synchronet 3.22a-Linux NewsLink 1.2

Who's Online
Recent Visitors
- Sauron
  Mon Aug 17 05:50:20 2026
  from Purgatory via Telnet
- Sauron
  Sun Aug 16 22:51:04 2026
  from Purgatory via Telnet
- Rixter
  Sun Aug 16 22:39:57 2026
  from Madison, Nc via Telnet
- Rixter
  Sun Aug 16 10:20:30 2026
  from Madison, Nc via Telnet

System Info

Sysop:	Amessyroom
Location:	Fayetteville, NC
Users:	74
Nodes:	6 (1 / 5)
Uptime:	51:13:43
Calls:	1,101
Calls today:	1
Files:	1,339
Messages:	276,016

Proposal: Improve BE naming convention in freebsd-update install

Who's Online

Recent Visitors

System Info