Date: Mon, 25 May 2026 14:25:21 -0700 From: "Edward Sanford Sutton, III" <mirror176@hotmail.com> To: stable@freebsd.org Subject: Re: Proposal: Improve BE naming convention in freebsd-update install Message-ID: <SA1PR11MB8811F2246BDB5E010B833854E60A2@SA1PR11MB8811.namprd11.prod.outlook.com> In-Reply-To: <be295f98-e6c8-4490-ac4a-fb26735b69d5@shirt.ocn.ne.jp> 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>
index | next in thread | previous in thread | raw e-mail
On 5/25/26 02:28, Takashi Shimizu wrote: > On 5/25/26 16:51, vermaden wrote: >> >> To understand 'default' name choose you will have to move back in time >> to 2012 when I implemented *beadm(8)* for FreeBSD: >> >> - https://forums.freebsd.org/threads/howto-freebsd-zfs-madness.31662/ >> >> The *pool/ROOT/default *was back then (and probably is still now) used >> by default on Solaris/Illumos - so I just recreated that - along with >> *beadm(8) *tool - its parameters and messages. >> >> Of course it can be changed - right now I use something like that >> personally: >> >> f25 vermaden ~ %*beadm list* >> BE Active Mountpoint Space Created >> 14.4 NR / 29.3G 2026-03-01 11:03 >> 14.4.safe.OLD - - 7.3G 2026-05-08 01:19 >> 14.4.safe - - 1.6G 2026-05-18 20:48 >> 15.0 - - 12.7G 2026-05-21 12:24 > > Thank you for the valuable responses. > > To clarify my proposal: I was not suggesting a naming convention for > users to follow manually. The intent was that freebsd-update itself > automatically renames the current BE to "HEAD" after each install. This > guarantees that "HEAD" always refers to the latest state managed by > freebsd-update, without any user intervention. 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. > I should be transparent that I was personally misled by the > automatically generated BE names and lost considerable time as a result. > The BE name said "p8" but the system was actually running "p9". The > snapshot with the newer timestamp turned out to be the older state. I > suspect other users have fallen into the same trap. 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. > I actively promote FreeBSD to Japanese users through social media, and > one of my key messages is that FreeBSD with ZFS and Boot Environments > allows safe and confident system updates. This proposal comes from a > wish to make that experience better for users who are new to FreeBSD. 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. > If it does not conflict with established conventions, I would be > grateful if this could be reconsidered. And even if the current behavior > remains unchanged, I am thankful that the topic was worth discussing. You were mislead by names and you were mislead by dates and make it sound like it wasn't just user error. Thank you for bringing attention and discussion to it. > Thank you for the links as well. I will read them carefully. > > Takashihome | help
Want to link to this message? Use this
URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?SA1PR11MB8811F2246BDB5E010B833854E60A2>