Installing or upgrading to FreeBSD 15 (CURRENT[?])

T

taiwan740

I'm interested in running the bleeding edge versions, as I'm essentially a hobbyist and none of my systems are critical, and I'd enjoy the testing and new features etc.

What is the process to go from RELEASE to CURRENT? Is there a specific process? I couldn't find anything in the handbook but I could have missed it.

I tried running the command below, not really expecting it to be that simple, and it didn't work.

Code: 
freebsd-update -r 15.0-CURRENT upgrade

Perhaps I need to clone the source repo and build /sys manually?
 
I don't think binary updates for CURRENT are made on a regular basis, so my opinion is if you are interested in running CURRENT I think build from source for base and building ports from source is the better path.
 
It's "worse" than that, -CURRENT snapshots are built with a lot of debugging stuff enabled that will hurt performance a lot. This is suitable for anyone doing active development on base. It's not suitable for actually using the system.

As a ports committer, I need a VM running -CURRENT for testing ports, and it should perform well (because I'm not interested in debugging issues with base itself, I just need to verify my ports work fine on -CURRENT). For that, I use the following settings in /etc/src.conf to build(!) -CURRENT:
Code: 
WITHOUT_ASSERT_DEBUG=yes
WITHOUT_LLVM_ASSERTIONS=yes
WITHOUT_TESTS=yes
WITH_MALLOC_PRODUCTION=yes
KERNCONF=GENERIC-NODEBUG

This is what you will need to run -CURRENT without any debugging foo.

taiwan740 -- please just forget about this "bleeding edge" nonsense. FreeBSD has a proven and reliable release engineering. If you want "bleeding edge", use the latest -RELEASE version. It's very rare to really NEED to run -CURRENT (e.g., like me, for testing ports ... or maybe because support for some hardware you need is indeed only available in -CURRENT). You will have to build it yourself. You will face ABI breakage any time (so, packages just fail, for example, this recently happened when 14-CURRENT moved from OpenSSL 1.1.x to OpenSSL 3.x). Keep in mind it IS an unstable development version. It will crash any time. It will destroy your data any time (as recently happened with some broken OpenZFS feature). Just don't ever use it if you can avoid it!

edit: that all said, the straight-forward answer to the question how to install -CURRENT is: you build it from source. You clone the src repository to /usr/src and build and install the system from there. The handbook has a chapter about installing/upgrading FreeBSD from source.
 
Everything regarding -CURRENT has already been said, except that -CURRENT is not a supported version here on the forums. If you have issues with it you will need to seek out the developers on the mailing lists.

taiwan740 said:
I tried running the command below, not really expecting it to be that simple, and it didn't work.
Click to expand...
Yep, freebsd-update(8) only works for -RELEASE versions. To upgrade to -STABLE or -CURRENT you will need to update and build from source.

taiwan740 said:
I'm interested in running the bleeding edge versions, as I'm essentially a hobbyist and none of my systems are critical, and I'd enjoy the testing and new features etc.
Click to expand...
Contrary to living on the absolute edge with -CURRENT, with all the risks that come with it, I can highly recommend doing -STABLE instead. A lot of things that are 'experimented' on in -CURRENT are eventually "MFC'ed". This is called "Merge From Current" and happens quite regularly in the stable branches. In a way the stable branch is the test bed for the next -RELEASE version. So you're always a few steps ahead of the curve.

taiwan740 said:
Perhaps I need to clone the source repo and build /sys manually?
Click to expand...
Almost, you need to build a bit more than that, /sys actually points to /usr/src/sys, and is where the kernel sources live. In order to update -STABLE or -CURRENT you will need to build(7) "world" as we say.
 
zirias@ said:
taiwan740 -- please just forget about this "bleeding edge" nonsense. FreeBSD has a proven and reliable release engineering. If you want "bleeding edge", use the latest -RELEASE version. It's very rare to really NEED to run -CURRENT (e.g., like me, for testing ports ... or maybe because support for some hardware you need is indeed only available in -CURRENT). You will have to build it yourself. You will face ABI breakage any time (so, packages just fail, for example, this recently happened when 14-CURRENT moved from OpenSSL 1.1.x to OpenSSL 3.x). Keep in mind it IS an unstable development version. It will crash any time. It will destroy your data any time (as recently happened with some broken OpenZFS feature). Just don't ever use it if you can avoid it!
Click to expand...
Thanks for the warning!

It's not so much about being actually "bleeding edge" (which I agree is nonsense) but I am interested in the process and the fact that it's a build-from-source task sounds exciting to me. I've got some dedicated hardware (ok, an old desktop...) that I can do this on (well, I'll probably do it in a VM and then dd the image when the time is right), so the risk to myself is only dented pride when I get it wrong.

Maybe I'll start off with -STABLE and then build -CURRENT using that or something
 
taiwan740 said:
Maybe I'll start off with -STABLE and then build -CURRENT using that or something
Click to expand...
If you set up boot environments you can actually use it to "dual" boot between -STABLE and -CURRENT if you want.

With regards to hardware, bigger is always better of course. But any fairly recent system will do. Building world just takes time (there are some 'tricks' you can use to speed up the process, with some caveats). Bigger, faster, hardware builds world faster. It can take a few hours or a few minutes. I find it kind of mesmerizing just staring at the output scroll by ?
 
taiwan740 said:
It's not so much about being actually "bleeding edge" (which I agree is nonsense) but I am interested in the process and the fact that it's a build-from-source task sounds exciting to me.
Click to expand...
FreeBSD's build system is very well integrated and easy to use, so maybe that's the "exciting" part, once you figured it out, it will just work, from building "world" and the kernel to installing everything and even removing old files from your system (and then there's a separate tool, etcupdate(8), to easily update your configuration in /etc by doing a 3-way merge, so your local changes are preserved). Just be sure to read and understand the relevant sections of the handbook first, so you carry out the build/install/upgrade process correctly.

But then, you have to decide what you actually want to do with your -CURRENT system. If you want to get into development, then build it with all the default debugging stuff enabled (which will make it slow). If you really want to just use it (which I still would not recommend), use the extra settings I posted above.

In any case, I'd also recommend to always enable "meta-mode", because you'll have to build often to keep your -CURRENT updated, and this avoids some unnecessary rebuilding and doesn't cost anything. For this, make sure you have the filemon(4) kernel module loaded and then put WITH_META_MODE=yes in /etc/src-env.conf.

SirDice already mentioned boot environments, I'd recommend to use them for every update, giving you a simple rollback option. This even gives the possibility to install everything into a new boot environment without touching your running system, so you don't even need to reboot after installing the kernel. After doing the buildworld and buildkernel steps, you'd do something like this:
Bash: 
bectl create new # new boot environment called "new"
bectl mount new /mnt # mount it ...
# and install everything there in one go, also removing anything but old libraries
make DESTDIR=/mnt BATCH_DELETE_OLD_FILES=yes installkernel installworld delete-old
etcupdate -D /mnt # update configs in the new be
bectl umount new
bectl activate -t new # activate the BE just for the next boot
 
zirias@ said:
default debugging stuff enabled (which will make it slow)
Click to expand...
I wouldn't really call it "slow", e.g.
Code: 
$ ll /etc/malloc.conf; sysctl debug.witness.watch; time (make -j20 buildkernel >/dev/null 2>&1); echo $?
ls: /etc/malloc.conf: No such file or directory
debug.witness.watch: 1
( make -j20 buildkernel > /dev/null 2>&1; )  3235.26s user 316.82s system 1811% cpu 3:16.10 total
0
vs
Code: 
$ ll /etc/malloc.conf; sysctl debug.witness.watch; time (make -j20 buildkernel >/dev/null 2>&1); echo $?
131591 lrwxr-xr-x  1 root wheel uarch 22 Sep  6 11:56 /etc/malloc.conf -> abort:false,junk:false
debug.witness.watch: 0
( make -j20 buildkernel > /dev/null 2>&1; )  2945.90s user 298.88s system 1806% cpu 2:59.60 total
0
...does NOT really make that much difference for me (done several times to make sure everything is in the ARC).

zirias@ said:
In any case, I'd also recommend to always enable "meta-mode", because you'll have to build often to keep your -CURRENT updated, and this avoids some unnecessary rebuilding and doesn't cost anything.
Click to expand...
This however cost me a *LOT* more of my time -- for some mysterious reasons meta mode is eager to rebuild llvm (and that's 3/4 of total build time for me) even on small unrelated changes so I switched back to using WITHOUT_CLEAN (and yet have to see any fallouts from "dumb" way of avoiding rebuilds).
 
yuripv79 said:
for some mysterious reasons meta mode is eager to rebuild llvm (and that's 3/4 of total build time for me) even on small unrelated changes so I switched back to using WITHOUT_CLEAN (and yet have to see any fallouts from "dumb" way of avoiding rebuilds).
Click to expand...
I think the reason is a recursive build relying on "dir dependencies" and, of course, llvm depends e.g. on the libc. So, when the libc changes, llvm is rebuilt. Completely. :rolleyes:

WITHOUT_CLEAN will avoid that, yes, but is not necessarily safe.

What meta-mode can do is reliably avoid rebuilding things when it can be determined by dependencies that it's unnecessary. To optimize further, I'd probably prefer using ccache over WITHOUT_CLEAN.
 
Dear zirias@,
zirias@ said:
To optimize further, I'd probably prefer using ccache over WITHOUT_CLEAN.
Click to expand...
What should the size for the cache be nowadays? I think the cache makes only sense if it matches to everything in total which will be compiled. A few years ago a few GByte (somewhere below 10) have not been sufficient already to cope with llvm, gcc and firefox all together.
 
chrbr as you mention gcc and firefox, I assume you are talking about a cache for both base and ports? Then I really can't give any meaningful answer, it will depend a lot on the list of ports you're building. But you can always check the ccache stats (how much of the cache is indeed used) and adapt if necessary...

When only talking about base, just for a rough estimation, my /usr/obj on a machine where I build release for both amd64 and i386 has 20GB, so my guess would be a well-working ccache for base should already have around 5 to 10GB.
 
taiwan740 said:
I'm interested in running the bleeding edge versions, as I'm essentially a hobbyist and none of my systems are critical, and I'd enjoy the testing and new features etc.
Click to expand...

You need to narrow down what you want to do, like test a new driver, and then follow a specific mailing list where those developers hang out.
Testing doesn't mean anything if you do not have a test plan or at least a test context, and testing the latest development code just like that is largely useless.

There is absolutely no reason to track CURRENT branch as an user.
If you want to build FreeBSD you can do your own builds based on RELEASE. If you're that enthusiastic, you can build STABLE to peek what's about to come.

The thing is, unless you're out for a specific feature that's so fresh that it's in STABLE but not in RELEASE, the normal release gives you exactly the same venues of tinkering. FreeBSD is a lot more flexible in configuration and does a lot of things out of the box. Things you'd have to install packages on Linux or maybe whole kernel modules.

So I highly recommend you stick to releases, tinker with making world+kernel from the release source.
I just wrote a couple of days ago, we need a big banner saying unless you're a developer or on a very specific case, RELEASE is for you.
 
I use bhyve virtual machines to run -current and -stable versions. The host runs -stable and is also where I build these versions. With appropriate options buildkernel + buildworld time is reduced to a few minutes (except when llvm needs to be rebuilt). This way I can see if things stay up in (simpler) VMs before updating the physical machines. And I can update VMs much more frequently than the physical machines without disrupting anything critical. Another nice thing about a VM is even more if you completely screw up, you can install the VM’s file system on the host and repair it (or grow it if you need to). Another script allows me to see commit logs since the running versions for each branch and optionally update sources for a branch.
 
Zare said:
we need a big banner saying unless you're a developer or on a very specific case, RELEASE is for you
Click to expand...
We need no such thing.
Zare said:
There is absolutely no reason to track CURRENT branch as an user.
Click to expand...
And there is absolutely no reason not to track CURRENT. "Developers" are not some mythical beings, they are grown up from "users" that are interested in learning more about the OS. The non-tech-savvy users (not that it's a bad thing) are all over there in Windows/macos land.
Zare said:
Testing doesn't mean anything if you do not have a test plan or at least a test context, and testing the latest development code just like that is largely useless.
Click to expand...
Completely disagree. "Test plans" and "test contexts" do not (and can not) cover every use case out there, while simply using OS for your daily needs helps discovering those bugs (that could be really specific to your use case) early.

CURRENT is not for everyone, correct, but actively turning everyone away from it (including some FUD like "it's crashing every 5 minutes" that I have seen on these forums) is wrong. I started following CURRENT in (pretty interesting) 5.x time and didn't look back (on my personal system, that is) and as I was interested in understanding the OS, every little challenge like build failures, program crashes or kernel panics got me some experience.
 
Zare and yuripv79 you have both valid points.

No, CURRENT does not "crash every 5 minutes", that would make my work testing ports on it completely impossible :cool: But also no, not every "non-tech-savvy" user stays away from FreeBSD in the first place ... and RELEASE versions undergo a release engineering process for a reason. In my earlier post here, I listed some breakage you should potentially expect with CURRENT, and those were real examples, and of course they don't happen every other day, but they will inevitably happen eventually.

I agree with Zare that it's important to explain to users that CURRENT potentially has these issues. I would add that there could be yet another misunderstanding for people knowing Linux distributions; with them, you often need to use whatever is "bleeding edge" in order to get up-to-date software. That is not the case for FreeBSD, ports are completely independent from base, you can always use the "latest" ports/packages with any supported FreeBSD version. So, indeed, people have to understand that CURRENT is not recommended for users.

I agree with yuripv79 that broader testing always helps. I agree no test plan would ever be perfect, and just having random users do random things potentially helps discovering more bugs. So anyone feeling adventurous "just because", sure, run CURRENT. If you report problems on bugzilla, or maybe the mailing list, in a good way (including as much information as possible), this will certainly help the project.

But in any case, bottom line is, CURRENT won't ever be "supported" on these forums. It's a moving target, and any communication about it should be in places where developers will see/notice it, like mailing lists and bugzilla.
 
yuripv79 said:
We need no such thing.
Click to expand...

This is a recurring thread, question gets asked over, because people who are new to FreeBSD think they'll get extra features with current.

yuripv79 said:
And there is absolutely no reason not to track CURRENT.
Click to expand...

Do you claim that CURRENT has same stability and ease of operation for non-tech-savvy users over RELEASE and they'll be smarter and more equipped to tackle FreeBSD once kernel panics?

yuripv79 said:
"Developers" are not some mythical beings, they are grown up from "users" that are interested in learning more about the OS. The non-tech-savvy users (not that it's a bad thing) are all over there in Windows/macos land...."Test plans" and "test contexts" do not (and can not) cover every use case out there, while simply using OS for your daily needs helps discovering those bugs (that could be really specific to your use case) early.
Click to expand...

I merged two quotes into one because I believe they're rooted in the same situation.
To perform testing you need to know what you're testing. E.g. I could boot up CURRENT and then report a bug about USB soundboard not working correctly, while IRL that feature has just started on the roadmap and only initial device support is commited. Raising a bug about it is useless.

Developers are users who have this knowledge. I am not referring to developers as a vocation but as a fixed group of FreeBSD commiters.

Again I fail to see how someone with general will to test stuff would benefit the community more with trying to tackle current than just using releases and reporting bugs around them which there are always plentiful. Most certainly, the OP is trying out the ecosystem and not just a specific hardware+base FreeBSD, the bugs they encounter will in all probabilities include 3rd party packages.

If OP is targeting systems programming and exploring FreeBSD in that context, then I draw back what I've said. But I don't think that's the case.

yuripv79 said:
CURRENT is not for everyone, correct, but actively turning everyone away from it (including some FUD like "it's crashing every 5 minutes" that I have seen on these forums) is wrong. I started following CURRENT in (pretty interesting) 5.x time and didn't look back (on my personal system, that is) and as I was interested in understanding the OS, every little challenge like build failures, program crashes or kernel panics got me some experience.
Click to expand...

I see your angle and I don't mean to gatekeep.

Its just that one needs to take N concretely documented steps in order to have -CURRENT running. The OP did not make it to step 1 without consulting the forum, the forum that will not be able to help them further if they complete the steps. I wanted to make sure OP understands what he's getting into, and more over, I want to understand what's his reason of not using RELEASE for the same cause.

I commend your dedication to CURRENT, I am using the system as daily driver since 5.4, and haven't used CURRENT if I really didn't have to which happened once or twice.
 
zirias@ said:
that broader testing always helps. I agree no test plan would ever be perfect, and just having random users do random things potentially helps discovering more bugs.
Click to expand...
True, upvote 1000x all the buzzwords.
I think this is especially true for the "generic PC platform". Every BIOS is a little different, every user is a different workload, all things that lead to overall better testing.

I think alot of folk come to FreeBSD with a Linux mindset where "bleeding edge" is only the kernel. Not "kernel plus base userland".
My Opinions:
RELEASE is suitable for 85% of users especially in a production environment.
STABLE is suitable for about 10% of the remaining users because of specific things that are MFC (hardware or specific bugs)
CURRENT is for everyone else, developers, port maintainers, testers.

For the record, I used to build from source all the time, tracking STABLE, but switched to following RELEASE and quarterly packages because it took too much of my time to rebuild everything (including ports) and I figured going fishing was a better use of time than watching a screen.

But hey, it's your boat, whatever floats it, I'm good.
 
mer said:
it took too much of my time to rebuild everything (including ports) and I figured going fishing was a better use of time than watching a screen.
Click to expand...
This is a good reason for *you* but there is no need to generalize. If anything we need more people who can donate their time to improving FreeBSD. Being curious is a good first step. Initially everyone flails about, trying to figure things out but with some help they can learn and eventually help others as well.

I stopped building ports locally a long time ago but still keep track of FreeBSD development some & once things are set up, it doesn’t take much time. For me it is more an ”idle” task and more interesting than wasting time on social media.
 
Almost all deliberate changes that go into -CURRENT will eventually make it into releases. Running -CURRENT to catch changes that break you as soon as possible, and spread out more in time, is perfectly reasonable.
 
cracauer@ said:
Almost all deliberate changes that go into -CURRENT will eventually make it into releases. Running -CURRENT to catch changes that break you as soon as possible, and spread out more in time, is perfectly reasonable.
Click to expand...
True! But with this motivation (as you ultimately want to avoid the breakage), you probably don't run -CURRENT as your daily driver but in some test environment (like spare machine, vm, ...) instead ?

Kind of repeating myself, of course, people doing that can help the project to achieve even better release quality!
 
All done, thanks all.

Code: 
FreeBSD [hostname] 15.0-CURRENT FreeBSD 15.0-CURRENT amd64 1500000 #0 main-n265228-c9315099f69e

I decided to 'dd' my 13.2 environment to a different drive for another machine (which I was going to do anyway) and run the 15.0 update on this machine. Only have an issue with amdgpu firmware after rebuilding for the new kernel, but that's not for this forum.

For hardware performance bragging rights (or lack thereof ? ):-

Code: 
>>> World built in 14160 seconds, ncpu: 4, make -j4

Edit: amdgpu issue fixed. Problem was I just needed to have a break and some lunch (gpu-firmware-kmod wasn't installed...)
 
You must log in or register to reply here.
Back
Top