Proper way to use -STABLE

jbo@

Developer
What is the proper/correct/recommended way of "using" -STABLE? Assuming an existing 13.0-RELEASE installation, is it as simple as running this:
Code:
freebsd-update -r 13.0-STABLE upgrade
or is there more to it?

Also, as per my understanding ports/packages are pretty unafected by this. I have a poudriere server building ports for 13.0 from HEAD. I take it that there won't be any issues and the same packages will run fine on 13.0-STABLE - is that correct?
 
Updating/upgrading -STABLE can only be done from source. You cannot use freebsd-update(8), that only works on -RELEASE versions.

Best way is to install devel/git and git clone the stable/13 branch. Then follow build(7).

Also, as per my understanding ports/packages are pretty unafected by this. I have a poudriere server building ports for 13.0 from HEAD. I take it that there won't be any issues and the same packages will run fine on 13.0-STABLE - is that correct?
99% of packages built for 13.0-RELEASE will work just fine. Few exceptions, anything that builds a kernel module needs to be specifically built for 13-STABLE. Same goes for any port that requires the use of kernel structures, sysutils/lsof for example.
 
99% of packages built for 13.0-RELEASE will work just fine. Few exceptions, anything that builds a kernel module needs to be specifically built for 13-STABLE. Same goes for any port that requires the use of kernel structures, sysutils/lsof for example.
How do I handle those cases? I am certainly using stuff like graphics/drm-kmod, sysutils/lsof and similar.

Would I need to setup a second jail in poudriere that runs 13.0-STABLE instead of 13.0-RELEASE and then end up with two repositories instead of just the one I have currently? Are there mechanisms to build just those few ports that rely on kernel modules/structures for 13.0-STABLE and use 13.0-RELEASE packages I already build anyway for the rest?
 
How do I handle those cases?
I have a poudriere bulk build specifically for 13-STABLE (both a server and a desktop build). After I run my updates for the system itself I also make a release(7) from that. I use that release to update my poudriere 13-STABLE jail. I'm currently hosting 4 repositories, a desktop and a server build for 13.0-RELEASE and 13-STABLE.
 
I'm reading through the handbook to understand better what actually needs to happen. One thing I'm currently still unclear on: When my plan is to get to 13.0-STABLE on a system currently running 13.0-RELEASE, do I just need to build the kernel or do I need to build world too?
 
When my plan is to get to 13.0-STABLE on a system currently running 13.0-RELEASE, do I just need to build the kernel or do I need to build world too?
Userland and kernel are tightly coupled, they're not separate entities as is the case with many Linux distributions. Your 'world' has to match up with your kernel.
 
[...] 99% of packages built for 13.0-RELEASE will work just fine. Few exceptions, anything that builds a kernel module needs to be specifically built for 13-STABLE.
Same goes for any port that requires the use of kernel structures, sysutils/lsof for example.

-STABLE refers to the stable ABI (=Application Binary Interface); see this message from Zirias (can't just find the reference on the FreeBSD site at this moment)

During development, code repositories are being held in a version control system. As preparation for a new major -RELEASE, -STABLE is branched off from -CURRENT (FreeBSD doesn't do HEAD anymore). -CURRENT is the main branch. For the most recent situation that is 13-STABLE. Development of the -CURRENT branch continues, from then on also known as 14-CURRENT. Changes made continiously in -CURRENT reflect code changes obviously but, also more specifically changes to the ABI.

I think everybody realizes that code/programs destined for 13.x-RELEASE is not intended for another major -RELEASE version, for example a 12.x-RELEASE. When you are building from -CURRENT you are basically building from and for a major FreeBSD version (N.B. in flux!) that has a distance from 13.x-RELEASE and 13-STABLE. That distance, with its differences, only gets bigger in time. From a previous thread:

freebsd_versions-png.9652


This (increasing with time) difference, especially with the 13-STABLE ABI being locked down and the -CURRENT ABI not being locked down reflects on what SirDice refers to as "[...] anything that builds a kernel module needs to be specifically built for 13-STABLE."
 
Last edited:
I would appreciate it if somebody could sanity-check my approach here:

Code:
git clone https://github.com/freebsd/freebsd-src
cd freebsd-src
cp sys/amd64/conf/GENERIC sys/amd64/conf/MYKERNEL
vim sys/amd64/conf/MYKERNEL   # Modify kernel options
sudo make buildworld KERNCONF=MYKERNEL
sudo make buildkernel KERNCONF=MYKERNEL
sudo make installworld KERNCONF=MYKERNEL
sudo make installkernel KERNCONF=MYKERNEL

Does this make sense?
 
i am not sure whether there is a proper way, but i run stable/13 since this branch created. i update maybe 3 times a month, but what i actually do is looking in git log or https://cgit.freebsd.org/src/log/?h=stable/13 changes to decide if updates are worth. I have thinkpad w520 and thinkpad t440p notebooks, just a regular boxes, nothing critical, so that i also reboot them often. What i also have is: my zfs root has only one dataset, so that bectl can handle it entirely, then i update in following way:
Code:
bectl create BE-$sha ( #matching git SHA of stable/13 )
bectl mount BE-$sha /mnt
make -j8 buildworld buildkernel
make installworld installkernel DESTDIR=/mnt
bectl umount BE-$sha
then i register this BE with bectl, reboot and try. if good i propagate that BE to be default and remove older ones. Sometime, if ABI changed, certain packages need rebuilt, if ABI change affecting them. This is not too often ( almost never needed for me since i started to use 13 branch ) and usually it is described in /usr/src/UPDATING. Yes, ideally, you need to rebuild packages, via poudriere
 
I would appreciate it if somebody could sanity-check my approach here:

Code:
git clone https://github.com/freebsd/freebsd-src
cd freebsd-src
cp sys/amd64/conf/GENERIC sys/amd64/conf/MYKERNEL
vim sys/amd64/conf/MYKERNEL   # Modify kernel options
sudo make buildworld KERNCONF=MYKERNEL
sudo make buildkernel KERNCONF=MYKERNEL
sudo make installworld KERNCONF=MYKERNEL
sudo make installkernel KERNCONF=MYKERNEL

Does this make sense?
Yes, but be aware, you clone HEAD aka CURRENT in this case!
i do git checkout stable/13 after clone
 
Code:
bectl create BE-$sha ( #matching git SHA of stable/13 )
bectl mount BE-$sha /mnt
make -j8 buildworld buildkernel
make installworld installkernel DESTDIR=/mnt
bectl umount BE-$sha
then i register this BE with bectl, reboot and try. if good i propagate that BE to be default and remove older ones. Sometime, if ABI changed, certain packages need rebuilt, if ABI change affecting them. This is not too often ( almost never needed for me since i started to use 13 branch ) and usually it is described in /usr/src/UPDATING. Yes, ideally, you need to rebuild packages, via poudriere
Hmm... I think I should look into boot environments... better now than later when I actually start using the machine for daily tasks...
I did look into this a few months ago but couldn't find a lot of information I'd deem suitable for someone with basic FreeBSD experience. I usually don't ask for this as the handbook is very sufficient & precise but is there some sort of "how-to boot environment" tutorial(s) you guys can recommend?

Yes, but be aware, you clone HEAD aka CURRENT in this case!
i do git checkout stable/13 after clone
Ah yes... I simply forgot that in my code snipped paste. It's missing a git switch -c stable/13 statement :)
 
-STABLE refers to the stable ABI (=Application Binary Interace); see this message from Zirias (can't just find the reference on the FreeBSD site at this moment)
This (increasing with time) difference, especially with the 13-STABLE ABI being locked down and the -CURRENT ABI not being locked down reflects on what SirDice refers to as "[...] anything that builds a kernel module needs to be specifically built for 13-STABLE."

Yes, definitely keep an eye on /usr/src/UPDATING,
Code:
20210626:
        Commit 841006678745 changed the internal KAPI between the krpc
        and nfsd modules.  As such, they must both be rebuilt from
        sources.
        __FreeBSD_version is bumped to 1300510.
Bumped the version. Which could lead to (external) kernel modules failing to load. This is related to ports/packages, not the kernel modules that come with the base OS, those will be automatically in sync with a proper (userland + kernel) build.
Code:
20211119:
        Bump __FreeBSD_version to 1300521 after merging LinuxKPI and
        net80211 changes in order to support building various wireless
        drivers.  This is to help other external consumers of LinuxKPI
        and net80211 to deal accordingly.
Also bumped the version, this one is specifically important for graphics/drm-kmod for example.

It's missing a git switch -c stable/13 statement
Use git checkout <branchname> instead.
 
SirDice this is basically boiling down to what you said earlier - I should (at least in my particular case) build world as well; not just the kernel. Is that correct or am I missing some information you're trying convey?

I am mainly interested in the new Intel WiFi driver as this particular machine I acquired comes with an Intel AX201 card.
 
build world as well; not just the kernel. Is that correct or am I missing some information you're trying convey?
Yes, but those version bumps might have an effect on some ports too. But as I said, 99% of the packages for 13.0-RELEASE won't have an issue with this, it's just a few you might be using, just something to lookout for. I build a complete repository specifically for 13-STABLE so I'm more confident all my packages are going to work on my 13-STABLE systems and I don't have to worry about these version bumps.

Does this make sense?
Looks good. I would recommend building the GENERIC kernel too, just having it ready to go is useful for testing purposes in case your custom kernel fails for some reason. I've added KERNCONF="MOLLY GENERIC" to /etc/make.conf, that way you don't have to supply it every time. During the buildkernel stage all kernels in KERNCONF will be built. In the installkernel phase only the first on the list will be installed.
 
Code:
cd freebsd-src 
cp sys/amd64/conf/GENERIC sys/amd64/conf/MYKERNEL 
vim sys/amd64/conf/MYKERNEL # Modify kernel options 
sudo make buildworld KERNCONF=MYKERNEL 
sudo make buildkernel KERNCONF=MYKERNEL 
sudo make installworld KERNCONF=MYKERNEL 
sudo make installkernel KERNCONF=MYKERNEL
Few important steps you appear to have forgotten here, the first is etcupdate(8) (previous versions used mergemaster(8)). Sometimes scripts get added/removed or defaults changed from /etc/. The last two steps are important for cleaning up, make delete-old and make delete-old-libs.
 
... is there some sort of "how-to boot environment" tutorial(s) you guys can recommend?
The following pages will give a good overview how to handle boot environments. bectl(8) and beadm(1) share the same command syntax.

- https://wiki.freebsd.org/BootEnvironments
- https://klarasystems.com/articles/managing-boot-environments/
- https://vermaden.wordpress.com/2018/08/24/new-zfs-boot-environments-tool/
- https://vermaden.wordpress.com/2021/02/23/upgrade-freebsd-with-zfs-boot-environments/

You could experiment in a VM first to get a feeling about BE's
 
SirDice I'm investigating options regarding poudriere building 13.0-STABLE packages for me. If I understand correctly, if I have a 12.2-RELEASE host poudriere won't be able to build 13.0-STABLE packages - is that correct?
If I have a 13.0-RELEASE host, would poudriere be able to build 13.0-STABLE packages on that host?

Just to be clear: In any case I would build for amd64 on an amd64 host. The difference is purely the host's FreeBSD version poudriere is running on.
 
If I understand correctly, if I have a 12.2-RELEASE host poudriere won't be able to build 13.0-STABLE packages - is that correct?
Correct. You can't run a newer version jail than the host.
If I have a 13.0-RELEASE host, would poudriere be able to build 13.0-STABLE packages on that host?
Technically no, 13-STABLE is newer than 13.0-RELEASE so this can lead to build issues. My build server runs 13-STABLE for this reason, because it's not a problem to build 12.2-RELEASE or 13.0-RELEASE packages on a 13-STABLE host.
 
Alright, setting up a 13.0-STABLE physical host is currently not an option for me. Therefore, I'd opt running a 13.0-STABLE bhyve VM on a 13.0-RELEASE host.

Is there a binary release (like a nighly build or something) of 13.0-STABLE that I can grab (eg. an ISO) for an easier initial setup of the VM?
 
I created a bhyve VM using the snapshot from 2021-11-18. After installing poudriere I tried creating the 13.0-STABLE jail:
Code:
poudriere jail -c -j 130Samd64 -v 13.0-STABLE -a amd64
However, creating the jail fails with:
Code:
Error: lib32.txz checksum mismatch

Any ideas what I'm missing or doing wrong?
Is poudriere unable to fetch a -STABLE base image? If so, am I supposed to create a jail matching the host system?
 
Any ideas what I'm missing or doing wrong?
Is poudriere unable to fetch a -STABLE base image? If so, am I supposed to create a jail matching the host system?
Seems like this did the trick:
Code:
poudriere jail -c -j 130Samd64 -m git+https -v stable/13 -a amd64
It seems to be able to fetch the source and is currently busy building.
 
I am mainly interested in the new Intel WiFi driver as this particular machine I acquired comes with an Intel AX201 card.
You should check if these changes in -stable. I believe you will need to follow directions in https://wiki.freebsd.org/WiFi/Iwlwifi, in particular the testing section. The bhyve pass through didn’t quite work for me.

I don’t bother with building pkgs from ports. I just rebuild drm-kmod with every kernel build. You can also add things like PORTS_MODULES+=graphics/gpu-firmware-kmod to /etc/src.conf to ensure these modules get built. Separately I track https://github.com/freebsd/drm-mod and symlink /usr/local/sys/modules/drm-kmod to its local copy so that I can revert back to an earlier commit if something breaks. There are some other hacks that will cut-down rebuild time. I typically do make -j8 buildworld buildkernel. And I just use the GENERIC kernel.

Basically, you’ll be spending a bunch of time tracking -stable & occasional breakage. Do this to help Bjoern Zeeb with his wifi work. If the main reason for running -stable is to use AX201, you’re better off using an older wifi pcie card.
 
Back
Top