Date: Tue, 26 May 2026 07:29:19 +0900 From: Takashi Shimizu <qqyr7xx9k@shirt.ocn.ne.jp> To: "Edward Sanford Sutton, III" <mirror176@hotmail.com>, stable@freebsd.org Subject: Re: Proposal: Improve BE naming convention in freebsd-update install Message-ID: <1ea23792-d34a-4cb3-a20e-cb4040fd8f4a@shirt.ocn.ne.jp> In-Reply-To: <SA1PR11MB8811F2246BDB5E010B833854E60A2@SA1PR11MB8811.namprd11.prod.outlook.com> References: <70da0c5b-c865-44e9-8c19-abb1cd779efe@shirt.ocn.ne.jp> <7a0f1e46-b18d-455d-9b1c-f93131dae0bb@interia.pl> <be295f98-e6c8-4490-ac4a-fb26735b69d5@shirt.ocn.ne.jp> <SA1PR11MB8811F2246BDB5E010B833854E60A2@SA1PR11MB8811.namprd11.prod.outlook.com>
index | next in thread | previous in thread | raw e-mail
[-- Attachment #1 --]
On 5/26/26 06:25, Edward Sanford Sutton, III wrote:
>
> My question is does freebsd-update create a BE from the current BE,
> update that offline BE, then switch it to be active BE of next boot or
> even now? Alternatively does it create a BE from the current BE which
> is left as is and then apply updates to the current BE which requires
> not changing the BE of next and future boots nor require switching
> what is currently mounted? I assume the second case is used but don't
> actually know.
> In the first case it needs to not only (re)name the new BE but also
> rename the current BE, and probably any and all other BEs or else you
> will get multiple 'HEAD' labels.
> In the second case it would seem like there is no needed rename but
> if you ever have to boot a different BE and then do an update there
> you end up with multiple 'HEAD' labels; every failed upgrade scenario
> where changing boot environments are used to correct it will cause
> multiple 'HEAD' labels. The idea of doing it without renaming means
> default/head/... represents an evolving state where you are normally
> working from. If left with this name instead of receiving a new name
> to represent the version it was upgraded to (which means a name has to
> be changed by the tool) then default/... is always the newest 'unless'
> the user has booted from another BE and either updated it with
> freebsd-update or made other 'updates' (package updates,
> configurations manually or automatically updated, etc.) while booted
> to it. All of the naming issues would be resolved in this case if
> freebsd-update always renamed the BE with its version and a timestamp
> that it was ran (BE creation time does not represent freebsd-update
> time and default/...'s creation time should be well before its backups
> are made as an update step) and we could completely drop default/...
> type of naming as we have a proper version + update time on 'every'
> freebsd-update altered BE. As a side effect, any user named BEs also
> would get renamed; a syntax check could be ran and it could be skipped
> or user-prompted for replacement decision before renaming but user
> kept names are only as good as the user sets.
> Always modifying the BE name after a freebsd-update modification of
> it to contain the version also addresses Tuomo's case though instead
> of having '(latest)' and a bunch of times, you know what version you
> are booting (and when it was created as that version if freebsd-update
> adds a timestamp to the name). I assume latest was supposed to be
> stated on only the latest update and restated once changing to another
> that would have been needing a -r. I assume that freebsd-update
> doesn't support updating stable and current branches so it would be
> user managed to try to create and label them when used.
>
>
> If an update tool is creating boot environments in the first case
> above then calling it p8 instead of p9 for a state that will contain
> p9 I'd consider a bug. If its the second case then upgrading from p8
> to p9 makes a p8 boot environment at that time before update (creating
> preinstall but post-download = bloat but saves another download if
> needing to retry) which makes sense but leaves no p9 labeled
> environment due to using default and therefore likely the tool never
> renaming any boot environments; the state is known so a versioned name
> could be given instead of default but that adds a rename step. A
> creation timestamp of a backup-state being made before upgrade such as
> in case 2 should always have a newer timestamp but not be the newer
> state; using the first case I gave is the only way that makes newer
> timestamps always mean newer data. Rather than use that complicated
> case it seems simpler to follow case 2, create a backup BE pre-update
> with timestamp in the description, rename the current be to the new
> version with current (=same) timestamp, apply the update to the
> current be and give it one final newer timestamp (unless your machine
> was too fast and its still the same time). Creation time is still a
> historical trait for the ZFS pool but the description's date tells us
> when things changed rather than when they were created. This
> eliminates the use of 'default' and again gives it a descriptive name
> which is required to not leave it as unclear.
>
Thank you for the detailed analysis of Case 1 and Case 2.
I agree that Case 2 is the right approach. It is clean and
straightforward. Renaming the current BE to reflect its new version
after freebsd-update install, while preserving the pre-update state with
a timestamped name, gives users all the information they need without
unnecessary complexity.
One of the things I love about FreeBSD is its simplicity and clarity of
commands, which stands in contrast to some other operating systems. I
hope this improvement can be implemented without adding undue complexity
to freebsd-update.
>
> As a side note, trying to upgrade a non-BE system to use a BE layout
> as deep boot environments was one of the few times in over 20 years of
> using FreeBSD as my desktop that I hit a state where I had to reload
> from backup. it was a mix of problems with my layout, I think I forgot
> to manually specify -r sometimes when migrating, managing, and/or
> experimenting, and I'm not sure that beadm has any support for deep
> boot environments (If wrong, I'd love to learn how its done and
> managed). Doesn't help that I didn't initially understand what was
> actually going on. Once in place and working properly its a pretty
> slick thing but its not a replacement for full pool snapshots and
> backups. The shallow boot environments seemed like a downgrade to my
> other use of ZFS layout and properties so that is why I went for deep.
> Upgrades go wrong so rarely that I'd likely have passed on BEs if I
> had to switch to shallow to use them. I've had some other ideas for it
> concept too like making multi-architecture boot media seems plausible.
> Over the years of mostly tracking stable some stuff did break with
> updates but that was rarely anything I didn't already find about from
> reading /usr/src/UPDATING or heard about on a mailing list. I can
> always download and build an update but not install it until later if
> I was actually worried so there was more time for issues to be brought
> up. I'm much more concerned about Windows updates breaking family
> members computers or what may happen next on a ddwrt upgrade than what
> happens if I install the next FreeBSD updates. It does take time to go
> through things like UPDATING on larger upgrades and I manually build
> ports on my now quite outdated desktop so build times and reading has
> me delay it longer than needed though looking back it seems the
> reading is not much more effort than a minor skim with little needed
> interaction and further steps from me.
>
> I've had 1 friend and 2 family members run FreeBSD on computers over
> those 20 years. Friend lost recovery media and as a temporary
> workaround on hard drive failure knew it wasn't Windows easy and I'd
> be there to help with questions but found other computer people were
> impressed when they copied+pasted commands from the handbook and they
> enjoyed that they got some 'upgrades' to their tasks compared to their
> previous Windows offerings. Only went back to Windows because the next
> computer came with it. One family member seemed to enjoy it to see
> something different and get some non-Microsoft playtime; stopped using
> it on next computer to simplify things. The other family member took
> up my offer of trying it as their fileserver at his small business and
> I'd put Windows on if needed; I had to come up with fixes to make it
> work how he wanted but the calls that I feared of the FreeBSD box
> failing him always turned out to be things like a bad network
> switch/cable or a simple fix; no longer used because the business was
> sold and next owner wanted to go to something different he knew
> (probably Linux but I forget). Onsite or not, upgrades didn't
> intimidate me on there and I didn't have ZFS of boot environments on
> them if memory serves.
>
I also agree that FreeBSD's update system is outstanding and highly
reliable. This is something that would be difficult to achieve on
operating systems where the kernel and base system are developed
separately. In practice, major updates on distributions such as Ubuntu
often fail to handle the complexity of such a split architecture,
leading to frequent problems and forcing users to reinstall from
scratch, much like Windows.
I quietly hope that Linux users who have grown tired of this situation
will find their way to FreeBSD. The barrier to moving from Linux to
FreeBSD is far lower than the barrier from Windows to Linux, after all.
Takashi
[-- Attachment #2 --]
<!DOCTYPE html>
<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=UTF-8">
</head>
<body>
<br>
<div class="moz-cite-prefix">On 5/26/26 06:25, Edward Sanford
Sutton, III wrote:<br>
</div>
<blockquote type="cite"
cite="mid:SA1PR11MB8811F2246BDB5E010B833854E60A2@SA1PR11MB8811.namprd11.prod.outlook.com"><br>
My question is does freebsd-update create a BE from the current
BE, update that offline BE, then switch it to be active BE of next
boot or even now? Alternatively does it create a BE from the
current BE which is left as is and then apply updates to the
current BE which requires not changing the BE of next and future
boots nor require switching what is currently mounted? I assume
the second case is used but don't actually know.
<br>
In the first case it needs to not only (re)name the new BE but
also rename the current BE, and probably any and all other BEs or
else you will get multiple 'HEAD' labels.
<br>
In the second case it would seem like there is no needed rename
but if you ever have to boot a different BE and then do an update
there you end up with multiple 'HEAD' labels; every failed upgrade
scenario where changing boot environments are used to correct it
will cause multiple 'HEAD' labels. The idea of doing it without
renaming means default/head/... represents an evolving state where
you are normally working from. If left with this name instead of
receiving a new name to represent the version it was upgraded to
(which means a name has to be changed by the tool) then
default/... is always the newest 'unless' the user has booted from
another BE and either updated it with freebsd-update or made other
'updates' (package updates, configurations manually or
automatically updated, etc.) while booted to it. All of the naming
issues would be resolved in this case if freebsd-update always
renamed the BE with its version and a timestamp that it was ran
(BE creation time does not represent freebsd-update time and
default/...'s creation time should be well before its backups are
made as an update step) and we could completely drop default/...
type of naming as we have a proper version + update time on
'every' freebsd-update altered BE. As a side effect, any user
named BEs also would get renamed; a syntax check could be ran and
it could be skipped or user-prompted for replacement decision
before renaming but user kept names are only as good as the user
sets.
<br>
Always modifying the BE name after a freebsd-update modification
of it to contain the version also addresses Tuomo's case though
instead of having '(latest)' and a bunch of times, you know what
version you are booting (and when it was created as that version
if freebsd-update adds a timestamp to the name). I assume latest
was supposed to be stated on only the latest update and restated
once changing to another that would have been needing a -r. I
assume that freebsd-update doesn't support updating stable and
current branches so it would be user managed to try to create and
label them when used.
<br>
<br>
</blockquote>
<p><br>
</p>
<blockquote type="cite"
cite="mid:SA1PR11MB8811F2246BDB5E010B833854E60A2@SA1PR11MB8811.namprd11.prod.outlook.com"><br>
If an update tool is creating boot environments in the first
case above then calling it p8 instead of p9 for a state that will
contain p9 I'd consider a bug. If its the second case then
upgrading from p8 to p9 makes a p8 boot environment at that time
before update (creating preinstall but post-download = bloat but
saves another download if needing to retry) which makes sense but
leaves no p9 labeled environment due to using default and
therefore likely the tool never renaming any boot environments;
the state is known so a versioned name could be given instead of
default but that adds a rename step. A creation timestamp of a
backup-state being made before upgrade such as in case 2 should
always have a newer timestamp but not be the newer state; using
the first case I gave is the only way that makes newer timestamps
always mean newer data. Rather than use that complicated case it
seems simpler to follow case 2, create a backup BE pre-update with
timestamp in the description, rename the current be to the new
version with current (=same) timestamp, apply the update to the
current be and give it one final newer timestamp (unless your
machine was too fast and its still the same time). Creation time
is still a historical trait for the ZFS pool but the description's
date tells us when things changed rather than when they were
created. This eliminates the use of 'default' and again gives it a
descriptive name which is required to not leave it as unclear.
<br>
<br>
</blockquote>
<br>
<p
class="font-claude-response-body break-words whitespace-normal leading-[1.7]">Thank
you for the detailed analysis of Case 1 and Case 2.</p>
<p
class="font-claude-response-body break-words whitespace-normal leading-[1.7]">I
agree that Case 2 is the right approach. It is clean and
straightforward. Renaming the current BE to reflect its new
version after freebsd-update install, while preserving the
pre-update state with a timestamped name, gives users all the
information they need without unnecessary complexity.</p>
<p
class="font-claude-response-body break-words whitespace-normal leading-[1.7]">One
of the things I love about FreeBSD is its simplicity and clarity
of commands, which stands in contrast to some other operating
systems. I hope this improvement can be implemented without adding
undue complexity to freebsd-update.</p>
<blockquote type="cite"
cite="mid:SA1PR11MB8811F2246BDB5E010B833854E60A2@SA1PR11MB8811.namprd11.prod.outlook.com"><br>
As a side note, trying to upgrade a non-BE system to use a BE
layout as deep boot environments was one of the few times in over
20 years of using FreeBSD as my desktop that I hit a state where I
had to reload from backup. it was a mix of problems with my
layout, I think I forgot to manually specify -r sometimes when
migrating, managing, and/or experimenting, and I'm not sure that
beadm has any support for deep boot environments (If wrong, I'd
love to learn how its done and managed). Doesn't help that I
didn't initially understand what was actually going on. Once in
place and working properly its a pretty slick thing but its not a
replacement for full pool snapshots and backups. The shallow boot
environments seemed like a downgrade to my other use of ZFS layout
and properties so that is why I went for deep. Upgrades go wrong
so rarely that I'd likely have passed on BEs if I had to switch to
shallow to use them. I've had some other ideas for it concept too
like making multi-architecture boot media seems plausible.
<br>
Over the years of mostly tracking stable some stuff did break
with updates but that was rarely anything I didn't already find
about from reading /usr/src/UPDATING or heard about on a mailing
list. I can always download and build an update but not install it
until later if I was actually worried so there was more time for
issues to be brought up. I'm much more concerned about Windows
updates breaking family members computers or what may happen next
on a ddwrt upgrade than what happens if I install the next FreeBSD
updates. It does take time to go through things like UPDATING on
larger upgrades and I manually build ports on my now quite
outdated desktop so build times and reading has me delay it longer
than needed though looking back it seems the reading is not much
more effort than a minor skim with little needed interaction and
further steps from me.
<br>
<br>
I've had 1 friend and 2 family members run FreeBSD on computers
over those 20 years. Friend lost recovery media and as a temporary
workaround on hard drive failure knew it wasn't Windows easy and
I'd be there to help with questions but found other computer
people were impressed when they copied+pasted commands from the
handbook and they enjoyed that they got some 'upgrades' to their
tasks compared to their previous Windows offerings. Only went back
to Windows because the next computer came with it. One family
member seemed to enjoy it to see something different and get some
non-Microsoft playtime; stopped using it on next computer to
simplify things. The other family member took up my offer of
trying it as their fileserver at his small business and I'd put
Windows on if needed; I had to come up with fixes to make it work
how he wanted but the calls that I feared of the FreeBSD box
failing him always turned out to be things like a bad network
switch/cable or a simple fix; no longer used because the business
was sold and next owner wanted to go to something different he
knew (probably Linux but I forget). Onsite or not, upgrades didn't
intimidate me on there and I didn't have ZFS of boot environments
on them if memory serves.
<br>
<br>
</blockquote>
<br>
<p
class="font-claude-response-body break-words whitespace-normal leading-[1.7]">I
also agree that FreeBSD's update system is outstanding and highly
reliable. This is something that would be difficult to achieve on
operating systems where the kernel and base system are developed
separately. In practice, major updates on distributions such as
Ubuntu often fail to handle the complexity of such a split
architecture, leading to frequent problems and forcing users to
reinstall from scratch, much like Windows.</p>
<p
class="font-claude-response-body break-words whitespace-normal leading-[1.7]">I
quietly hope that Linux users who have grown tired of this
situation will find their way to FreeBSD. The barrier to moving
from Linux to FreeBSD is far lower than the barrier from Windows
to Linux, after all.</p>
<p
class="font-claude-response-body break-words whitespace-normal leading-[1.7]">Takashi</p>
</body>
</html>
home |
help
Want to link to this message? Use this
URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?1ea23792-d34a-4cb3-a20e-cb4040fd8f4a>