Van: Takashi Shimizu <[email protected]> Datum: zondag, 24 mei 2026 13:53 Aan: [email protected] Onderwerp: Proposal: Improve BE naming convention in freebsd-update install
Hi, I'd like to propose an improvement to the Boot Environment naming convention used by freebsd-update. Current behavior and problems Here is a typical bectl list output after several freebsd-update runs: BE Active Mountpoint Space Created 15.0-RELEASE-p2_2026-02-11_220708 - - 5.22G 2026-02-11 22:07 15.0-RELEASE-p4_2026-04-23_104906 - - 2.55G 2026-04-23 10:49 15.0-RELEASE-p5_2026-04-23_103138 - - 69.5M 2026-04-23 10:31 15.0-RELEASE-p6_2026-05-06_110219 - - 579M 2026-05-06 11:02 15.0-RELEASE-p8_2026-05-21_183216 NR / 31.2G 2026-05-21 18:32 15.0-RELEASE-p8_2026-05-24_153246 - - 1.29M 2026-05-24 15:32 15.0-RELEASE_2026-02-01_103504 - - 179M 2026-02-01 10:35 default - - 1.22G 2026-02-01 10:29 This output raises several problems: The name "default" is misleading. It suggests "the BE that boots by default" or "the latest running state", but in practice it is just the residue of the initial installation, with no NR flag. The name and its actual purpose are mismatched. freebsd-update install updates the current BE in place, then saves a snapshot of the pre-update state with a new date-stamped name. As a result, the actual content of the current BE does not match its name. In the example above, 15.0-RELEASE-p8_2026-05-21_183216 has the NR flag and is the running system, but its actual content is 15.0-RELEASE-p9, installed by freebsd-update. The name says p8, but the system is running p9. This is highly misleading, especially when trying to recover from a failed reboot. Furthermore, the snapshot taken just before the update, 15.0-RELEASE-p8_2026-05-24_153246, has a newer timestamp than the current BE. The BE with the newer date is actually the older state. If a reboot fails and the user needs to identify which BE to activate, the date-based names actively mislead them. As upgrades accumulate, date-stamped BEs proliferate with no clear indication of which is current and which are fallbacks. Proposal Rename the initial installation BE from "default" to "original". This accurately reflects its purpose as a preserved baseline. After each freebsd-update install, rename the current BE to "HEAD". HEAD always refers to the latest BE created automatically by freebsd-update. User-created BEs are outside the scope of this convention and should be managed by the user themselves, with names of their own choosing such as "RELEASE-p9-preRC1". The result would be a bectl list that is immediately understandable: BE Active Mountpoint Space Created HEAD NR / 31.2G 2026-05-24 RELEASE-p9-preRC1 - - 1.5G 2026-05-24 15.0-RELEASE-p6_2026-05-06 - - 579M 2026-05-06 15.0-RELEASE-p2_2026-02-11 - - 5.22G 2026-02-11 original - - 1.22G 2026-02-01 HEAD is always the latest state managed by freebsd-update. User-created BEs with meaningful names serve as fallbacks for specific purposes. "original" is preserved as a historical baseline. This change would make the BE state self-explanatory, reduce confusion after failed upgrades, and lower the risk of users activating the wrong BE during recovery. Note: As FreeBSD transitions from freebsd-update to pkgbase, it would be worth considering whether pkgbase will provide automatic BE creation and a clear naming convention from the start, rather than inheriting the same confusion. Thanks for considering this. Takashi
Hi, I've read the rest of the thread also but reply on this one as it keeps the context of your question. Bectl does not tell the user how to name the "active" BE. You can see which is active by the NR parameters. You probably activated 15.0-RELEASE-p8_2026-05-21_183216 yourself in the past and then it sticks with that name. Because that is the BE you choose. If you want it to have another name, you can easily rename it yourself on your system. bectl rename 15.0-RELEASE-p8_2026-05-21_183216 HEAD After the next run of freebsd-update you will have a new timestamped BE, but the active and updated one will still be named HEAD. 🥳 NB: Renaming a BE can give issues when using zfs send | zfs receive to a backup system. As the names on the backup didn't change, the ZFS filesystems+snapshots on the backup are out of sync now. Regards, Ronald.
