Solved Updating from -RELEASE to -STABLE

J

jbo@

Developer
Is there anything I should know if I were to embark on converting an existing FreeBSD 13.0-RELEASE desktop to stable/13? I have a machine already running stable/13 but that was freshly installed as such.

Any gotchas, special procedures or such for this endeavour? Or do I just follow the same procedure I would if I were updating an already stable/13 machine to a later state of stable/13?
 
jbodenmann said:
Any gotchas, special procedures or such for this endeavour?
Click to expand...
Nope. Just make sure you're on the right branch.

Or do I just follow the same procedure I would if I were updating an already stable/13 machine to a later state of stable/13?
Click to expand...
I would suggest always reading /usr/src/UPDATING, but most of time you just have to follow the same basic steps; buildworld, buildkernel, etc.
 
If you start off with a 13.0-RELEASE you can make a boot environment of that too. Then you can switch between 13.0-RELEASE and 13-STABLE.
 
Exactly what I had in mind!

I remember that "back then" I didn't use boot environments because I seem to remember that they required a specific ZFS dataset layout. However, from what I can tell a freshly installed 13.0-RELEASE machine already satisfies these requirements. Based on the man pages this seems to be a very straight forward process.
 
jbodenmann said:
I remember that "back then" I didn't use boot environments because I seem to remember that they required a specific ZFS dataset layout. However, from what I can tell a freshly installed 13.0-RELEASE machine already satisfies these requirements.
Click to expand...
Yep, the standard install has since been modified to make it directly usable with beadm(1) or bectl(8). So you should be good to go right out of the box.
 
SirDice said:
Yep, the standard install has since been modified to make it directly usable with beadm(1) or bectl(8).
Click to expand...
I think perhaps: beadm(8)

There is some history, for example here:
grahamperrin said:
[...] The first two or three posts here might be mind-bending.
Post #11 puts things in context.
[...] beadm
Erichans said:
[...] both beadm(1) and beadm(8) exist: that should be fixed at the FreeBSD website [...]
Click to expand...



FreeBSD bug 254466 – sysutils/beadm-devel section (1) and sysutils/beadm section (8) for the two manual pages for beadm; consequences
  • closed
  • works as intended – Wolfram Schneider's comment 13 was key to understanding, after which I edited the summary line of the bug.
Effective:
Click to expand...

Comparing:
combined with the remark by Slawomir Wojciech Wojtczak here:
I think that *sysutils/beadm-devel* can be deleted as it was not updated since 3 years ...
Click to expand...
By the looks of it: sysutils/beadm-devel/ mostly receiving administrative actions/updates and only recently "synchronizing" some stuff for both.

Also:
  1. beadm() (i.e: [man]beadm[/man] ) hides beadm(8) (i.e: [man=8]beadm[/man] )
  2. similarly: beadm (i.e.: with "all Sections selected") hides beadm (i.e.: with "Section 8 selected")
It is apparently very easy to get beadm(1) & beadm(8) mixed up(*). It also does not help that at one point in time sysutils/beadm/ changed its man page from Section 1 to Section 8.

I agree with Slawomir Wojciech Wojtczak and I think it is time to retire sysutils/beadm-devel/ (2012-09-04) including its beadm(1) and delete it. I cannot find a message to that effect. Who has jurisdiction (for lack of a better word) and what would be the best way to proceed: file a new PR as suggested here?

___
(*) beadm(1) from sysutils/beadm-devel/ and beadm(8) from sysutils/beadm/ seem to co-exist on the FreeBSD man page website:
Because of the absence of a resolution mechanism, e.g. a namespace where the port name is included, these man pages can co-exist on the FreeBSD man page website. In an actual FreeBSD installation these cannot co-exist because the two ports are mutually exclusive.
 
Retiring that one will leave other cases, and attention to the ports tree is not the answer …

forums.freebsd.org

Manual pages online: RFD – share your thoughts on changes to design

Hint The first two or three posts here might be mind-bending. Post #10 puts things in context. beadm … both beadm(1) and beadm(8) exist: that should be fixed at the FreeBSD website …𡀦 FreeBSD bug 254466 – sysutils/beadm-devel section (1) and sysutils/beadm section (8) for the two manual...
forums.freebsd.org forums.freebsd.org
 
I agree that a general solution for problematic man pages on the FreeBSD man pages website is warranted(1). However, I do not see name collisions or other problems with man pages that are about a subject of similar importance as beadm.

beadm(1) of sysutils/beadm-devel versus beadm(8) of sysutils/beadm is relevant now; it relates to supported FreeBSD releases.
  • For FreeBSD users not in the know: which one to choose? It is confusing for users as to which beadm is which and which one belongs to what port.
  • For sysutils/beadm-devel, the developer and port maintainer has indicated: it can be deleted.
  • This is about a crucial FreeBSD installation topic: boot environments. Especially important during the transition process of upgrading from 12.x to 13.x, since there are some changes to the boot environment to consider.
  • Its use as compared to bectl(8) is being discussed now: Boot environments utility
It would be nice to be all be on the same page, the beadm(8) man page that is :)

[…] attention to the ports tree is not the answer …
Click to expand...
I disagree, at its core beadm(1) versus beadm(8) is a port problem. sysutils/beadm-devel is not being developed (as opposed to maintained). A port (i.e.: sysutils/beadm) that has as its sibling a separate development port that, for all intents and purposes, has come to a standstill has served its purpose. Deleting the development port means: less maintenance, less confusion, one less port to choose from and, yes, indeed one less source of confusion on the FreeBSD man pages website and this forum.

Currently, for the beadm problem, the options are:
  1. wait for a future better systemic solution(2) and do nothing about beadm(1) versus beadm(8)
  2. delete the port sysutils/beadm-devel with beadm(1) and solve this one problem easily
At the moment IMO #2 is the right thing to do.

___
(1) that will take some fundamental changes and development work that does not seem in the making: mailing-list and PR-256676
(2) at which time FreeBSD users still have to choose between a non-dev version of the port and a separate dev-port that is not being developed anymore ...
 
Last edited:
Erichans said:
… choose between a non-dev version of the port and …
Click to expand...

There's a more basic choice:
  • whether to add anything.
SirDice said:
… good to go right out of the box.
Click to expand...

👍

Essentially:
  • bectl is integral to the operating system
  • add beadm only if you can't get what's required from the operating system
– and without wishing to over-generalise, the most distinctive aspect of bectl is that it proceeds without confirmation.
 
In general: if users start with intro(1), then look at the other intro pages (like intro(8)) they will get a feel for what tools are supposed to do.
But - it requires a bi of reading versus just starting to use a system and then figure it out along the learning path.
 
You must log in or register to reply here.
Back
Top