Upgrading from 14.3 to 15.0

kerogaz

kerogaz

Is it possible to directly upgrade from FreeBSD 14.3 to 15.0 when the release is released or do I need to upgrade to 14.4 first?It's not clear, because versions 14.4 and 15.0 are released at the same time.
 
kerogaz said:
Is it possible to directly upgrade from FreeBSD 14.3 to 15.0 when the release is released or do I need to upgrade to 14.4 first?
Click to expand...
Yes. You don't need to upgrade to 14.4 first, release process for that hasn't even started yet.

kerogaz said:
It's not clear, because versions 14.4 and 15.0 are released at the same time.
Click to expand...
There are almost always 2 major version that are supported, at this time that's 14 and a 'legacy' major version 13. When 15 is released, 13 will soon be EoL, 14 will become the 'legacy' version and 15 the 'latest' released version.
 
kerogaz said:
So, 15.0 is coming out before 14.4? That's weird.
Click to expand...
Yes. Not weird though, they are different major branches. Expect to see something like 15.0-RELEASE, then 14.4-RELEASE, then 15.1-RELEASE, then 14.5-RELEASE, 15.2-RELEASE, etc. The 14 branch will get new minor releases until it's EoL (November 2028).
 
No, you can switch to 15.0-RELEASE in a couple of days. Release builds have started today and will be formally announced in a couple of days.

www.freebsd.org

FreeBSD 15.0 Release Process

FreeBSD is an operating system used to power modern servers, desktops, and embedded platforms.
www.freebsd.org www.freebsd.org

kerogaz said:
which version of FreeBSD 14 can I upgrade to 15.0 from?
Click to expand...
From any 14 or 13 version. The only thing to watch out for is a couple of bugs in freebsd-update(8) if you upgrade from a really old version. But if your 14.3-RELEASE is up to date with the latest patches you don't need to worry about that.
 
I don't have the details on how the build cluster works, and my personal anecdotal evidence is firmly in the n=1 territory, but I'd give it a bit of time after RELEASE drops before trying to upgrade a machine with many packages. Especially the bigger ones like Rust and packages that depend on Elektron need some time to land.
 
siealex said:
Aren't these packages built simultaneously for all current versions?
Click to expand...
Sure, still takes quite a lot of time to build everything though. Then it has to be transferred to all the mirrors. I agree with bvdw78 enthusiasm is fine, but you should know what you're getting in to. Best way is to wait for the announcement, then you can be sure everything's in place and ready to go.
 
Time to build, time to push, time to address any pkg fallout (failure to build package A may cascade to everything depending on A). So waiting a day or 5 may save you alot of pain.

Oh and ZFS saves pain. You can do the upgrade "in place" (using the chroot option) so you can create a ZFS Boot Environment and do a complete upgrade into it; base and packages That gives you a coherent BE to try. Very helpful if you are using things like Nvidia, Intel or AMD drm kmods.
 
mer said:
Very helpful if you are using things like Nvidia, Intel or AMD drm kmods.
Click to expand...
Very helpful with any kind of upgrade/update. Never used it that excessively myself, but I know how to deal with an eventual fall-out. Broke my systems on many occasions in the past 25 years, mostly due to my own dumb mistakes. You learn a lot that way :D
 
kerogaz said:
So, it's possible to switch to 15.0 in about a year?
Click to expand...
Or three. I think the 14.x release will be supported until sometime in 2028.

Personally, I upgrade as late as possible; I just added to my calendar: upgrading from my current 13.5 to 14.x, in March 2026, about a month before support for 13.x ends. And since the changes between 14.x and 15.x are much more significant, that upgrade (sometime in 2028) will need a few weeks of testing on a sacrificial machine, and I may decide to change to a different OS instead.
 
SirDice said:
Very helpful with any kind of upgrade/update. Never used it that excessively myself, but I know how to deal with an eventual fall-out. Broke my systems on many occasions in the past 25 years, mostly due to my own dumb mistakes. You learn a lot that way :D
Click to expand...
Pain. That's the best way to learn sometimes. Insert meme of Clubber Lang from Rocky III movie.

Myself? I've settled on explicit BE for major version upgrade. 12.x to 13.x, 13.x to 14.x . Going to a new minor release, I just let freebsd-update handle the new BE; it actually creates (by default) a new BEFORE updating so your "current" BE is the new stuff, the auto created BE is before so I wind up renaming BEs to reflect what they contain.
May not be the way everyone does it/should do it, but works for me.
Just need to remember freebsd-update creates those BEs and you should trim them every now and again.
 
siealex said:
How to do this?
Click to expand...
bectl list then bectl destroy {...} whatever isn't needed anymore. Take note of the R and N flags in the list; bectl(8).

Code: 
		 Display all boot environments.	 The  Active  field  indicates
		 whether the boot environment is active	now (N); active	on re-
		 boot  (R);  is	 used on next boot once	(T); or	combination of
		 (NRT).
 
How I do it:
bectl list to get a list of the currently created BEs. On my system:
bectl list
BE Active Mountpoint Space Created
14.3-RELEASE-p1 - - 354M 2025-08-09 19:10
14.3-RELEASE-p2 NR / 14.3G 2025-07-18 12:54

Pay attention to the column labeled "Active".
N means "Active Now" or "I am currently booted into this one"
R means "Reboot will use this one"

To get rid of unneeded BEs:
bectl destroy -o "bename"

So in my example I would do
bectl destroy -o 14.3-RELEASE-p1

This is a trivial example but freebsd-update will create a new BE everytime it actually updates, so the sysadmin MUST be aware and trim things.
Space in a BE is roughly "deltas", so 14.3-p1 to 14.3-p2 not too much. But if you start crossing releases (14.x to 15.x, 13.x to 14.x) you will have big deltas and potentially lots of space to recover.

You can safely remove every BE that is not "N" or "R" (I tend to keep 1 back).
 
If this command spits a long list like this:

Code: 
root@freebsd:/home/alex # bectl list
BE                                Active Mountpoint Space Created
14.1-RELEASE-p5_2024-12-03_212249 -      -          17.3M 2024-12-03 21:22
14.1-RELEASE-p6_2024-12-03_212829 -      -          1.50M 2024-12-03 21:28
14.1-RELEASE_2024-10-17_014001    -      -          417M  2024-10-17 04:40
14.2-RELEASE-p1_2025-02-23_014349 -      -          1.29G 2025-02-23 01:43
14.2-RELEASE-p2_2025-04-08_034820 -      -          66.4M 2025-04-08 03:48
14.2-RELEASE-p2_2025-04-10_231051 -      -          433M  2025-04-10 23:10
14.2-RELEASE-p3_2025-06-07_152841 -      -          2.64M 2025-06-07 15:28
14.2-RELEASE_2024-12-03_213019    -      -          1.61M 2024-12-03 21:30
14.2-RELEASE_2025-01-30_160358    -      -          176M  2025-01-30 16:03
14.3-RELEASE-p1_2025-08-16_120621 -      -          6.79G 2025-08-16 12:06
14.3-RELEASE-p2_2025-09-21_190424 -      -          323M  2025-09-21 19:04
14.3-RELEASE-p3_2025-10-02_121303 -      -          244M  2025-10-02 12:13
14.3-RELEASE-p4_2025-10-22_202437 -      -          1.64G 2025-10-22 20:24
14.3-RELEASE-p5_2025-11-28_162053 -      -          287M  2025-11-28 16:20
14.3-RELEASE_2025-06-07_153037    -      -          2.19M 2025-06-07 15:30
14.3-RELEASE_2025-07-04_040653    -      -          7.73G 2025-07-04 04:06
250122-000444                     -      -          176M  2025-01-22 00:04
default                           NR     /          91.6G 2024-10-17 04:28

is it enough to keep "default"?
 
:) Yes keeping default should be enough. Start at 14.1-RELEASE-p5_2024-12-03_212249 with "bectl destroy -o" and do bectl list after that. It's interesting watching what happens with the "space".
 
You must log in or register to reply here.
Back
Top