From nobody Tue May 26 08:24:52 2026 X-Original-To: freebsd-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 4gPm5T59XJz6fZd9 for ; Tue, 26 May 2026 08:25:01 +0000 (UTC) (envelope-from ronald-lists@klop.ws) Received: from smtp-relay-int-backup.realworks.nl (smtp-relay-int-backup.realworks.nl [87.255.56.188]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 4gPm5S4rZkz45bh for ; Tue, 26 May 2026 08:25:00 +0000 (UTC) (envelope-from ronald-lists@klop.ws) Authentication-Results: mx1.freebsd.org; dkim=pass header.d=klop.ws header.s=rw2 header.b=UVAh0i79; dmarc=pass (policy=quarantine) header.from=klop.ws; spf=pass (mx1.freebsd.org: domain of ronald-lists@klop.ws designates 87.255.56.188 as permitted sender) smtp.mailfrom=ronald-lists@klop.ws Received: from smtp-relay-int-backup.realworks.nl (crmpreview4.colo2.realworks.nl [10.2.52.34]) by mailrelayint2.colo2.realworks.nl (Postfix) with ESMTP id 4gPm5K2V8RzBq; Tue, 26 May 2026 10:24:53 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=klop.ws; s=rw2; t=1779783893; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: in-reply-to:in-reply-to:references:references; bh=JDt0Mdb8i7MgjOGzBNVfbDaiyTZ7bEIFDsW8u2UHpFE=; b=UVAh0i79yPgiOWF4ekcCLMYG/PS3iSeEMPsWsqZ4+yG6ZBLsbcGq7WO85oIALkoZjf1fq5 /HuIbjulErnbbsdn1OlLfyF6DGAVlS7twPY7iN+x5A0CufdCKu+CrE5SedRZsdl/h5Zyr8 yNMjGZHigp8BwS0XHLv5v0X0O2bnBphFYipBX0uvMHg8EIgrmcaPhllXRkLdW6L8hSfaed qAjjUsATjbJzeQ02IAjgnhxNiaHz9igvYRkSCjZFmeEau2THFIcPz7iwxWQ57HDdEr3kxJ ex6LoWtGpLmwzz1PSaAoT6trjeShu4Ak2gpkFqhVODCfaNPz9/0owXpWw6OL2A== Received: from crmpreview4.colo2.realworks.nl (localhost [127.0.0.1]) by crmpreview4.colo2.realworks.nl (Postfix) with ESMTP id DEC0B1C00E4; Tue, 26 May 2026 10:24:52 +0200 (CEST) Date: Tue, 26 May 2026 10:24:52 +0200 (CEST) From: Ronald Klop To: Takashi Shimizu Cc: freebsd-stable@freebsd.org Message-ID: <1676824497.1245.1779783892574@localhost> In-Reply-To: <70da0c5b-c865-44e9-8c19-abb1cd779efe@shirt.ocn.ne.jp> References: <70da0c5b-c865-44e9-8c19-abb1cd779efe@shirt.ocn.ne.jp> Subject: Re: Proposal: Improve BE naming convention in freebsd-update install 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 Content-Type: multipart/alternative; boundary="----=_Part_1244_1356603490.1779783892407" X-Mailer: Realworks (796.113) X-Originating-Host: from (83-81-213-118.cable.dynamic.v4.ziggo.nl [83.81.213.118]) by crmpreview4.colo2.realworks.nl [10.2.52.34] with HTTP; Tue, 26 May 2026 10:24:52 +0200 Importance: Normal X-Priority: 3 (Normal) X-Originating-User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.15; rv:151.0) Gecko/20100101 Firefox/151.0 X-Spamd-Result: default: False [-3.50 / 15.00]; NEURAL_HAM_LONG(-1.00)[-1.000]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; NEURAL_HAM_SHORT(-1.00)[-0.999]; MID_RHS_NOT_FQDN(0.50)[]; DMARC_POLICY_ALLOW(-0.50)[klop.ws,quarantine]; R_DKIM_ALLOW(-0.20)[klop.ws:s=rw2]; R_SPF_ALLOW(-0.20)[+ip4:87.255.56.128/26]; MIME_GOOD(-0.10)[multipart/alternative,text/plain]; TO_MATCH_ENVRCPT_SOME(0.00)[]; ASN(0.00)[asn:38930, ipnet:87.255.32.0/19, country:NL]; ARC_NA(0.00)[]; FROM_HAS_DN(0.00)[]; MIME_TRACE(0.00)[0:+,1:+,2:~]; RCVD_TLS_LAST(0.00)[]; FROM_EQ_ENVFROM(0.00)[]; RCPT_COUNT_TWO(0.00)[2]; RCVD_COUNT_TWO(0.00)[2]; HAS_X_PRIO_THREE(0.00)[3]; TO_DN_SOME(0.00)[]; MLMMJ_DEST(0.00)[freebsd-stable@freebsd.org]; DKIM_TRACE(0.00)[klop.ws:+] X-Spamd-Bar: --- X-Rspamd-Queue-Id: 4gPm5S4rZkz45bh ------=_Part_1244_1356603490.1779783892407 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: quoted-printable =20 Van: Takashi Shimizu Datum: zondag, 24 mei 2026 13:53 Aan: freebsd-stable@freebsd.org Onderwerp: Proposal: Improve BE naming convention in freebsd-update install >=20 > Hi, >=20 > I'd like to propose an improvement to the Boot Environment naming convent= ion used by freebsd-update. >=20 > Current behavior and problems >=20 > Here is a typical bectl list output after several freebsd-update runs: >=20 > 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: >=20 > The name "default" is misleading. It suggests "the BE that boots by defau= lt" or "the latest running state", but in practice it is just the residue o= f the initial installation, with no NR flag. The name and its actual purpos= e are mismatched. >=20 > freebsd-update install updates the current BE in place, then saves a snap= shot 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 a= bove, 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-upd= ate. The name says p8, but the system is running p9. This is highly mislead= ing, especially when trying to recover from a failed reboot. >=20 > Furthermore, the snapshot taken just before the update, 15.0-RELEASE-p8_2= 026-05-24_153246, has a newer timestamp than the current BE. The BE with th= e newer date is actually the older state. If a reboot fails and the user ne= eds to identify which BE to activate, the date-based names actively mislead= them. >=20 > As upgrades accumulate, date-stamped BEs proliferate with no clear indica= tion of which is current and which are fallbacks. >=20 > Proposal >=20 > Rename the initial installation BE from "default" to "original". This acc= urately reflects its purpose as a preserved baseline. >=20 > After each freebsd-update install, rename the current BE to "HEAD". HEAD = always refers to the latest BE created automatically by freebsd-update. Use= r-created BEs are outside the scope of this convention and should be manage= d by the user themselves, with names of their own choosing such as "RELEASE= -p9-preRC1". >=20 > The result would be a bectl list that is immediately understandable: >=20 > 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 B= Es with meaningful names serve as fallbacks for specific purposes. "origina= l" is preserved as a historical baseline. >=20 > This change would make the BE state self-explanatory, reduce confusion af= ter failed upgrades, and lower the risk of users activating the wrong BE du= ring recovery. >=20 > 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 con= fusion. >=20 > 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 pa= st 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 y= our 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, bu= t the active and updated one will still be named HEAD. =F0=9F=A5=B3 NB: Renaming a BE can give issues when using zfs send | zfs receive to a ba= ckup system. As the names on the backup didn't change, the ZFS filesystems+= snapshots on the backup are out of sync now. Regards, Ronald. =20 ------=_Part_1244_1356603490.1779783892407 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: quoted-printable  

Van: Takashi Shimizu <qqyr7xx9k@shirt.ocn.ne.jp><= br> Datum: zondag, 24 mei 2026 13:53
Aan: freebsd-stable@freebsd.org
Onderwerp: Proposal: Improve BE naming convention in freeb= sd-update install

Hi,

I'd like to propose an improvement to the Boot Environment naming conven= tion used by freebsd-update.

Current behavior and problems

Here is a typical bectl list output after several freebsd-update runs: 

BE                                Active Mountpoint Space   Crea=
ted
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:

    =09
  1. =09

    The name "default" is misleading. It suggests "the BE that boots by d= efault" or "the latest running state", but in practice it is just the resid= ue of the initial installation, with no NR flag. The name and its actual pu= rpose are mismatched.

    =09
    2. =09
  2. =09

    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 examp= le above, 15.0-RELEASE-p8_2026-05-21_183216 has the NR flag and is the runn= ing 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 mis= leading, especially when trying to recover from a failed reboot.

    =09
    3. =09
  3. =09

    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 wit= h the newer date is actually the older state. If a reboot fails and the use= r needs to identify which BE to activate, the date-based names actively mis= lead them.

    =09
    4. =09
  4. =09

    As upgrades accumulate, date-stamped BEs proliferate with no clear in= dication of which is current and which are fallbacks.

    =09

Proposal

    =09
  • =09

    Rename the initial installation BE from "default" to "original". This= accurately reflects its purpose as a preserved baseline.

    =09
    • =09
  • =09

    After each freebsd-update install, rename the current BE to "HEAD". H= EAD always refers to the latest BE created automatically by freebsd-update.= User-created BEs are outside the scope of this convention and should be ma= naged by the user themselves, with names of their own choosing such as "REL= EASE-p9-preRC1".

    =09

The result would be a bectl list that is immediately understandable:

BE                                Active Mountpoint Space   Crea=
ted
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. "origin= al" is preserved as a historical baseline.

This change would make the BE state self-explanatory, reduce confusion a= fter failed upgrades, and lower the risk of users activating the wrong BE d= uring 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 co= nfusion.

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 yours= elf in the past and then it sticks with that name. Because that is the BE y= ou choose.
If you want it to have another name, you can easily rename it yourself on y= our 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, bu= t the active and updated one will still be named HEAD. =F0=9F=A5=B3

NB: Renaming a BE can give issues when using zfs send | zfs receive to a ba= ckup system. As the names on the backup didn't change, the ZFS filesystems+= snapshots on the backup are out of sync now.

Regards,
Ronald.
  ------=_Part_1244_1356603490.1779783892407--