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
