# Proper way to use -STABLE



## jbo (Nov 25, 2021)

What is the proper/correct/recommended way of "using" -STABLE? Assuming an existing 13.0-RELEASE installation, is it as simple as running this:

```
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?


----------



## covacat (Nov 25, 2021)

i always cvsuped / svnuped to -STABLE and made world
dont think you can binary track -STABLE


----------



## SirDice (Nov 25, 2021)

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). 



jbodenmann said:


> 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.


----------



## jbo (Nov 25, 2021)

SirDice said:


> 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?


----------



## SirDice (Nov 25, 2021)

jbodenmann said:


> 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.


----------



## jbo (Nov 25, 2021)

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?


----------



## SirDice (Nov 25, 2021)

jbodenmann said:


> 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.


----------



## Erichans (Nov 25, 2021)

SirDice said:


> [...] 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:







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."


----------



## jbo (Nov 25, 2021)

I would appreciate it if somebody could sanity-check my approach here:


```
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?


----------



## angry_vincent (Nov 25, 2021)

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:

```
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


----------



## angry_vincent (Nov 25, 2021)

jbodenmann said:


> I would appreciate it if somebody could sanity-check my approach here:
> 
> 
> ```
> ...


Yes, but be aware, you clone HEAD aka CURRENT in this case!
i do git checkout stable/13 after clone


----------



## jbo (Nov 25, 2021)

angry_vincent said:


> ```
> bectl create BE-$sha ( #matching git SHA of stable/13 )
> bectl mount BE-$sha /mnt
> make -j8 buildworld buildkernel
> ...


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?



angry_vincent said:


> 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


----------



## SirDice (Nov 25, 2021)

Erichans said:


> -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)





Erichans said:


> 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, 

```
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. 

```
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.



jbodenmann said:


> It's missing a `git switch -c stable/13` statement


Use `git checkout <branchname>` instead.


----------



## jbo (Nov 25, 2021)

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.


----------



## SirDice (Nov 25, 2021)

jbodenmann said:


> 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.



jbodenmann said:


> 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.


----------



## SirDice (Nov 25, 2021)

jbodenmann said:


> ```
> cd freebsd-src
> cp sys/amd64/conf/GENERIC sys/amd64/conf/MYKERNEL
> vim sys/amd64/conf/MYKERNEL # Modify kernel options
> ...


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`.


----------



## T-Daemon (Nov 25, 2021)

jbodenmann said:


> ... 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


----------



## jbo (Nov 25, 2021)

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.


----------



## SirDice (Nov 25, 2021)

jbodenmann said:


> 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. 


jbodenmann said:


> 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.


----------



## eternal_noob (Nov 25, 2021)

SirDice said:


> Correct. You can't run a newer version jail than the host.


This information is missing in the handbook. It mentions the `-v` switch but no word on that restriction.
(No, i won't create a PR, for reasons)


----------



## jbo (Nov 25, 2021)

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?


----------



## eternal_noob (Nov 25, 2021)

Yes, look here: https://download.freebsd.org/ftp/snapshots/amd64/amd64/ISO-IMAGES/13.0/

Edit: Here are dedicated images to be used in a VM: https://download.freebsd.org/ftp/snapshots/VM-IMAGES/13.0-STABLE/amd64/Latest/


----------



## jbo (Nov 25, 2021)

eternal_noob said:


> Yes, look here: https://download.freebsd.org/ftp/snapshots/amd64/amd64/ISO-IMAGES/13.0/


I created a bhyve VM using the snapshot from 2021-11-18. After installing poudriere I tried creating the 13.0-STABLE jail:

```
poudriere jail -c -j 130Samd64 -v 13.0-STABLE -a amd64
```
However, creating the jail fails with:

```
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?


----------



## jbo (Nov 25, 2021)

jbodenmann said:


> 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:

```
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.


----------



## bakul (Nov 25, 2021)

jbodenmann said:


> 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.


----------



## SirDice (Nov 25, 2021)

eternal_noob said:


> This information is missing in the handbook.


Poudriere uses jail(8), a lot. Each build job is set up from a clean jail. This 'limitation' is because a jail runs on the host's kernel. The host kernel can only support up to version X, running a X+1 userland will cause problems. There's _backwards_ compatibility, not forward. 

To run 12, 11 or other, previous version jails (or executables in general) you need to have a kernel with the COMPAT_FREEBSD12, COMPAT_FREEBSD11, etc. Just in case you decide to build a custom kernel and remove all those. The GENERIC kernel has them enabled by default.


----------



## grahamperrin@ (Dec 2, 2021)

eternal_noob said:


> …
> 
> https://download.freebsd.org/ftp/snapshots/VM-IMAGES/13.0-STABLE/amd64/Latest/



FreeBSD bug 259090 – UFS: bad file descriptor: soft update journaling can not be enabled on FreeBSD-provided disk images for 13.0-RELEASE and 13.0-STABLE – failed to write updated cg



jbodenmann said:


> … I think I should look into boot environments... better now than later …



True, and I suggest habitually booting a new environment before any upgrade (or installation that will affect an already installed package).

Here (-CURRENT):

```
% bectl list -c creation
BE                    Active Mountpoint Space Created
n250511-5f73b3338ee-d -      -          4.36G 2021-11-13 15:43
n250650-ef396441ceb-c -      -          1.13G 2021-11-28 03:02
n251146-d109559ddbf-a -      -          86.7M 2021-11-29 22:14
n251146-d109559ddbf-b NR     /          76.0G 2021-12-02 02:11
%
```

– `n251146-d109559ddbf-a` and `n251146-d109559ddbf-b` are the same base OS. First _-a_, then I created and booted _-b_ before the first `pkg upgrade`.



jbodenmann said:


> ```
> …
> sudo make buildworld KERNCONF=MYKERNEL
> sudo make buildkernel KERNCONF=MYKERNEL
> ...



If you'll take something like that approach, then you must (at least) correct the order.

<https://forums.freebsd.org/posts/544209> ▶ <https://cgit.freebsd.org/src/tree/UPDATING?id=e641c29a006ae9f528f196386052355b42a53d75#n2455> where installation of the kernel *precedes* installation of world.

I assume that `KERNCONF` has no effect on world.



SirDice said:


> … 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. …



Thanks, so `KERNCONF` can never affect `buildkernel` (do I understand correctly)?



jbodenmann said:


> … a 13.0-STABLE physical host is currently not an option for me. …



Please, why not? (Have I misunderstood something on page 1?)



jbodenmann said:


> … easier initial setup …



All things considered, I reckon <https://www.freebsd.org/where/#_freebsd_13_0_stable> use an installer for (not an image of) 13.0-STABLE; and install to ZFS.


----------



## grahamperrin@ (Dec 2, 2021)

jbodenmann remind me, please, is this case one that might sometimes involve graphics/drm-devel-kmod/ with 13.0-STABLE? 

Or (around <https://forums.freebsd.org/posts/543681>) is it solely Wi-Fi that causes you to lean away from 13.0-RELEASE?


----------



## SirDice (Dec 2, 2021)

grahamperrin said:


> Thanks, so `KERNCONF` can never affect `buildkernel` (do I understand correctly)?


No, KERNCONF tells `buildkernel` _which_ kernels to build. If you do not set KERNCONF only GENERIC gets build.


----------



## grahamperrin@ (Dec 4, 2021)

Thanks, and apologies. Speed reading, I mis-read this:



SirDice said:


> 𡀦… During the buildkernel stage all kernels in `KERNCONF` will be built. …



(I saw "all kernels" but overlooked the context.)


For when I next update 14.0-CURRENT from source: 


```
% head -n 2 /etc/src.conf
# <https://forums.freebsd.org/posts/544812>
KERNCONF="GENERIC-NODEBUG GENERIC"
%
```

In the CURRENT context, is `GENERIC` debug-enabled?

No mention of _debug_ at or around <https://docs.freebsd.org/en/books/handbook/cutting-edge/#makeworld>.

(For performance, I normally boot GENERIC-NODEBUG, but it'll be smart to have a debug-enabled kernel handy, when required.)


----------



## grahamperrin@ (Jan 14, 2022)

SirDice said:


> … During the buildkernel stage all kernels in `KERNCONF` will be built. …





grahamperrin said:


> `KERNCONF="GENERIC-NODEBUG GENERIC"`



I might have had a problem with that part of /etc/src.conf a few hours ago. Retrying now, I hope to have the result in a few hours. 

(Previously, I mistakenly overrode the _file_ line by following a habit, in the history of my shell, of specifying `KERNCONF=GENERIC-NODEBUG` at the _command_ line.)


----------



## rigoletto@ (Jan 14, 2022)

jbodenmann said:


> I would appreciate it if somebody could sanity-check my approach here:
> 
> 
> ```
> ...



`#make buildworld; make kernel[1]...`

[1] no need to build and install the kernel using separated commands, and the kernel should (advised) be installed before world. Also, this is advised to reboot in single user (or at least drop to it) before installing world.


----------



## grahamperrin@ (Jan 14, 2022)

rigoletto@ said:


> … reboot in single user (or at least drop to it) before installing world.







grahamperrin said:


> <https://cgit.freebsd.org/src/tree/UPDATING?id=e641c29a006ae9f528f196386052355b42a53d75#n2455>



The footnote _currently_ numbered 3, for the single user mode routine, can be improved, as can the FreeBSD Handbook.


A 2004 revision wrote `cd src` instead of `cd /usr/src`, a later revision expanded the line:

`cd src                  # full path to source`

People are more likely to be familiar with /usr/src as demonstrated in the Handbook:

<https://docs.freebsd.org/en/books/handbook/book/#updating-src-quick-start>
<https://docs.freebsd.org/en/books/handbook/cutting-edge/#updating-src-quick-start>


The Handbook lacks the single user mode advice, which (according to UPDATING) is required i.e. *essential* for a major upgrade.


Instead of `sh /etc/rc.d/zfs start`, I run `service zfs onestart`. Easier to type.


Where `mount -u /` is followed by `mount -a`, would `mount -uw /` be a preferable first command?


----------



## jbo (Jan 14, 2022)

rigoletto@ said:


> Also, this is advised to reboot in single user (or at least drop to it) before installing world.


Can you provide a bit more information on this subject? What's the reasoning behind this?


----------



## grahamperrin@ (Jan 14, 2022)

make installworld and single-user mode
					

When it comes to make installworld this should be done in single-user mode. In Absolute FreeBSD 2nd Ed. (M.W.Lucas 2008, p. 395f.) can be read some lowlevel changes in the system require the install in the single-user mode. I’d like to ask what these lowlevel changes might be and when they...




					forums.freebsd.org


----------



## grahamperrin@ (Jan 14, 2022)

grahamperrin said:


> a problem with that part of /etc/src.conf a few hours ago. Retrying now,




```
root@mowa219-gjp4-8570p-freebsd:/usr/src # tail buildkernel.log
--- buildkernel ---
make[1]: "/usr/src/Makefile.inc1" line 330: SYSTEM_COMPILER: Determined that CC=cc matches the source tree.  Not bootstrapping a cross-compiler.
make[1]: "/usr/src/Makefile.inc1" line 335: SYSTEM_LINKER: Determined that LD=ld matches the source tree.  Not bootstrapping a cross-linker.
make[1]: "/usr/src/Makefile.inc1" line 1635: Missing KERNCONF /usr/src/sys/amd64/conf/"GENERIC-NODEBUG GENERIC"

make[1]: stopped in /usr/src

make: stopped in /usr/src
root@mowa219-gjp4-8570p-freebsd:/usr/src # nano /etc/src.conf
```


----------



## rigoletto@ (Jan 14, 2022)

jbodenmann said:


> Can you provide a bit more information on this subject? What's the reasoning behind this?


`intallworld` basically is installing over the whole world you are using. Doing it on _live_ system increase the chances of something went wrong during the process, and so this is better to be done over the system running at its _minimum_. In fact, if you want to do everything _anally_ correct you should do the whole building/installing process in single user mode.


----------



## grahamperrin@ (Jan 14, 2022)

rigoletto@ said:


> you should do the whole building/installing process in single user mode.



I can't imagine a problem with building. I always build world then kernel, whilst using my desktop environment e.g. KDE Plasma.

Side note: I'll probably move this response after my earlier post has been moved.


----------



## bakul (Jan 15, 2022)

You shouldn't *build* the system in single user mode. Not all things may be set up properly and you may have to do so manually.

The proper build steps are documented in /usr/src/Makefile starting at line 78 or so. Just replace mergemaster with etcupdate (or bectl).


----------



## grahamperrin@ (Jan 15, 2022)

bakul said:


> The proper build steps are documented in /usr/src/Makefile



It's outdated, not a good point of reference. FreeBSD bug 260822 – /usr/src/Makefile needs to be updated for etcupdate in comments

Above, we have links to documentation that is less outdated.



bakul said:


> You shouldn't *build* the system in single user mode. Not all things may be set up properly and you may have to do so manually.



Thanks.


----------



## grahamperrin@ (Jan 22, 2022)

grahamperrin said:


> `KERNCONF="GENERIC-NODEBUG GENERIC"`



That was wrong. Instead, currently commented out: 


```
% grep NODEBUG /etc/src.conf
# KERNCONF=GENERIC GENERIC-NODEBUG
KERNCONF=GENERIC-NODEBUG
%
```

*without* quotation marks.


----------



## meaw229a (Jan 23, 2022)

grahamperrin said:


> That was wrong. Instead, currently commented out:
> 
> 
> ```
> ...


I actually tried this earlier today and it did not work for me. I'm on stable and want to build without debug.
Make stopped directly after starting it.


----------



## grahamperrin@ (Jan 23, 2022)

meaw229a said:


> … it did not work for me. I'm on stable and want to build without debug.
> 
> Make stopped directly after starting it.



I'm sorry about that. It might be a few hours before I can boot a virtual machine with stable/13, to compare.

Does the GENERIC-NODEBUG file exist for you? 


```
$ file /usr/src/sys/amd64/conf/GENERIC-NODEBUG
/usr/src/sys/amd64/conf/GENERIC-NODEBUG: ASCII text
$
```


----------



## meaw229a (Jan 24, 2022)

Thanks for your reply. No the GENERIC-NODEBUG file is not in this folder. 
What code needs to be in this file?


----------



## grahamperrin@ (Jan 24, 2022)

Now I see, GENERIC-NODEBUG is not in stable/13:

<https://github.com/freebsd/freebsd-src/tree/stable/13/sys/amd64/conf/>


----------



## Phishfry (Jan 24, 2022)

If you look at the GENERIC kernconf for 13-STABLE you will notice all the debug features are removed.
Thusly no need for a NODEBUG kernel.


```
# Debugging support.  Always need this:
options     KDB            # Enable kernel debugger support.
options     KDB_TRACE        # Print a stack trace for a panic.
```

FreeBSD Main

```
# Debugging support.  Always need this:
options     KDB            # Enable kernel debugger support.
options     KDB_TRACE        # Print a stack trace for a panic.
# For full debugger support use (turn off in stable branch):
options     BUF_TRACKING        # Track buffer history
options     DDB            # Support DDB.
options     FULL_BUF_TRACKING    # Track more buffer history
options     GDB            # Support remote GDB.
options     DEADLKRES        # Enable the deadlock resolver
options     INVARIANTS        # Enable calls of extra sanity checking
options     INVARIANT_SUPPORT    # Extra sanity checks of internal structures, required by INVARIANTS
options     QUEUE_MACRO_DEBUG_TRASH    # Trash queue(2) internal pointers on invalidation
options     WITNESS            # Enable checks to detect deadlocks and cycles
options     WITNESS_SKIPSPIN    # Don't run witness on spinlocks for speed
options     MALLOC_DEBUG_MAXZONES=8    # Separate malloc(9) zones
options     VERBOSE_SYSINIT=0    # Support debug.verbose_sysinit, off by default
```


----------



## SirDice (Jan 24, 2022)

-CURRENT typically has a whole bunch of debug options enabled by default. Most of these are already disabled on -STABLE and -RELEASE versions.


----------



## grahamperrin@ (Jan 24, 2022)

Phishfry said:


> If you look at the GENERIC kernconf for 13-STABLE you will notice all the debug features are removed.
> 
> …
> 
> ...





SirDice said:


> -CURRENT typically has a whole bunch of debug options enabled by default. Most of these are already disabled on -STABLE and -RELEASE versions.



Thank you both. 

I took my first ever look at the _contents_ of GENERIC and GENERIC-NODEBUG in `main` following a hint from cperciva@ (Colin Percival) whilst forums were unavailable: 

<https://old.reddit.com/r/freebsd/comments/rya5pz/-/hsxy91c/>

For anyone who's curious: 


```
% cat /usr/src/sys/amd64/conf/GENERIC-NODEBUG | grep -v \#

include GENERIC
include "../../conf/std.nodebug"

ident   GENERIC-NODEBUG
options         TSLOG
% uname -KU
1400048 1400048
%
```

I should probably have the `TSLOG` line elsewhere, and use an include, but it's only one line and if I do lose it: it's memorable.









						freebsd-src/std.nodebug at main · freebsd/freebsd-src
					

FreeBSD src tree (read-only mirror). Contribute to freebsd/freebsd-src development by creating an account on GitHub.




					github.com


----------



## grahamperrin@ (Jan 24, 2022)

Performance and debug-readiness

STABLE

Before today I _assumed_, maybe wrongly:

that `STABLE` is _somehow_ more debug-ready than `ALPHA⋯`, `BETA⋯` and `RELEASE`; and
that `STABLE` might be _marginally_ less performant than `RELEASE`.
Please, is either assumption true?

Sorry for the assumptions. I simply never had an opportunity to test `STABLE` quantitively, or qualitatively, with performance in mind.

CURRENT

Re: <https://forums.freebsd.org/posts/504539> I don't doubt that there's an impact on performance for some use cases. 

For myself, honestly, I can't tell a difference between `GENERIC` and `GENERIC-NODEBUG`. Both perform equally well.


----------



## Phishfry (Jan 25, 2022)

grahamperrin said:


> that `STABLE` might be _marginally_ less performant than `RELEASE`.


Unless sub-systems were worked on I would say same performance.
I am talking STABLE and RELEASE on same major version.

For example iflib came with 12.0-RELEASE.
On ethernet testing 12-STABLE would be faster than-12.0-RELEASE because iflib was tweaked within 12.

Some additional benefits of STABLE are new devices are backported from CURRENT in some cases.
(MFC=Merge from Current (to stable)).


----------



## Phishfry (Jan 25, 2022)

grahamperrin said:


> For myself, honestly, I can't tell a difference between `GENERIC` and `GENERIC-NODEBUG`. Both perform equally well.


I only run CURRENT on arm and I can say it sucks the life out of those little boards.
Almost crippling.


----------



## grahamperrin@ (Jan 25, 2022)

Thanks, 



Phishfry said:


> I only run CURRENT on arm … Almost crippling.



Boot time, or every day use?

Anyone: how does `CURRENT` `GENERIC-NODEBUG` (on ARM) compare to `STABLE` or `RELEASE` `GENERIC` (on ARM)?


ARM aside, I have a boot time of sixty-nine seconds, but it doesn't bother me, because desktop environment performance is more than adequate.


----------



## Phishfry (Jan 31, 2022)

grahamperrin said:


> Boot time, or every day use?





> *WARNING: WITNESS option enabled, expect reduced performance.*


I think that says it all. All the time. Not nearly as bad on rock64 as BBB


----------



## Phishfry (Jan 31, 2022)

grahamperrin said:


> What's that?


BeagleboneBlack. It is going on 10 years old now


----------

