From nobody Mon May 25 22:29:19 2026 X-Original-To: stable@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 4gPVtF6dtJz6g6vp for ; Mon, 25 May 2026 22:29:25 +0000 (UTC) (envelope-from qqyr7xx9k@shirt.ocn.ne.jp) Received: from ocn-ckd-mts-207c40.ocn.ad.jp (ocn-ckd-mts-207c40.ocn.ad.jp [210.163.237.105]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 4gPVtF2KLWz3XxM for ; Mon, 25 May 2026 22:29:24 +0000 (UTC) (envelope-from qqyr7xx9k@shirt.ocn.ne.jp) Authentication-Results: mx1.freebsd.org; none Received: from ocn-spm-mts-209c1.ocn.ad.jp (ocn-spm-mts-209c1.ocn.ad.jp [210.145.246.238]) by ocn-ckd-mts-207c40.ocn.ad.jp (Postfix) with ESMTP id 19BC13C0005A0; Tue, 26 May 2026 07:29:20 +0900 (JST) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=shirt.ocn.ne.jp; s=20240118; t=1779748160; bh=ZRk+JY1YiZlrHkT8ssEXklEhg9ZXlp6h9xpy0UxjyF4=; h=Date:Subject:To:References:From:In-Reply-To:From; b=L/cDhbF5ivI4V5YcWuF3lr0xRnvXtAcE/6TuCe+YbDKDvqqWR5IjCUGNPIN8Optw5 ppLn+VPUXk3DVe4Ft+TXVN80iCak+BeH98SGY91Un0vZNsWp3idv4Y+tz6XbOPLnf2 cZRFuGcCN1lWC9cPSvgCuiKzHr0zTwk1KdV3PIW9v+AHRgozpqVaHT+f4RfMap+ATY N0BtalQcF+YXmNfVWz5O4TbloEthOWL1k+K1opXvEWD0ohIcoLwp2cq7VFvo1MXR1S b0ALKT6BGxPjUfBdrj5ICIWQP8GERE86WTKiG6MkzpncixFo6c9bX+g7S52RiIuiWT RQL22U44f4QGQ== Received: from ocn-vc-mts-210c1.ocn.ad.jp ([210.145.250.232]) by ocn-spm-mts-209c1 with ngmta id 50fe5819-18b2ef85a55e8154; Tue, 26 May 2026 07:29:20 +0900 Received: from ocn-sdpx-mts-204c1.ocn.ad.jp ([210.145.249.141]) by ocn-vc-mts-210c1 with ngmta id 497cf2a6-18b2ef859d97d7d4; Tue, 26 May 2026 07:29:19 +0900 Received: from [192.168.1.11] (p1634144-ipxg05401yosida.nagano.ocn.ne.jp [153.185.242.144]) by ocn-sdpx-mts-204c1.ocn.ad.jp (Postfix) with ESMTPA; Tue, 26 May 2026 07:29:19 +0900 (JST) Content-Type: multipart/alternative; boundary="------------xMQxIO4uDBLGrgBl0Kr4jpwM" Message-ID: <1ea23792-d34a-4cb3-a20e-cb4040fd8f4a@shirt.ocn.ne.jp> Date: Tue, 26 May 2026 07:29:19 +0900 List-Id: Production branch of FreeBSD source code List-Archive: https://lists.freebsd.org/archives/freebsd-stable List-Help: List-Post: List-Subscribe: List-Unsubscribe: X-BeenThere: freebsd-stable@freebsd.org Sender: owner-freebsd-stable@FreeBSD.org List-Id: List-Post: List-Help: List-Subscribe: List-Unsubscribe: List-Owner: Precedence: list MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: Proposal: Improve BE naming convention in freebsd-update install To: "Edward Sanford Sutton, III" , stable@freebsd.org References: <70da0c5b-c865-44e9-8c19-abb1cd779efe@shirt.ocn.ne.jp> <7a0f1e46-b18d-455d-9b1c-f93131dae0bb@interia.pl> Content-Language: en-US From: Takashi Shimizu In-Reply-To: X-Spamd-Result: default: False [-4.00 / 15.00]; REPLY(-4.00)[]; ASN(0.00)[asn:4713, ipnet:210.160.0.0/14, country:JP] X-Rspamd-Queue-Id: 4gPVtF2KLWz3XxM X-Spamd-Bar: ---- X-Rspamd-Pre-Result: action=no action; module=replies; Message is reply to one we originated This is a multi-part message in MIME format. --------------xMQxIO4uDBLGrgBl0Kr4jpwM Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit 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 --------------xMQxIO4uDBLGrgBl0Kr4jpwM Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: 8bit
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

--------------xMQxIO4uDBLGrgBl0Kr4jpwM--