Re: Proposal: Improve BE naming convention in freebsd-update install

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