Proper way to use -STABLE

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.
 

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

… 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):
Code:
% 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.

Code:
…
sudo make buildworld KERNCONF=MYKERNEL
sudo make buildkernel KERNCONF=MYKERNEL
sudo make installworld KERNCONF=MYKERNEL
sudo make installkernel KERNCONF=MYKERNEL

Does this make sense?

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.

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

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

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

… 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.
 
Last edited:
Thanks, and apologies. Speed reading, I mis-read this:

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

Code:
% 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.)
 
… During the buildkernel stage all kernels in KERNCONF will be built. …

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

#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.
 
… reboot in single user (or at least drop to it) before installing world.

👍


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:



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?
 
 
a problem with that part of /etc/src.conf a few hours ago. Retrying now,

Code:
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
 
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.
 
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.
 
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).
 
That was wrong. Instead, currently commented out:

Code:
% grep NODEBUG /etc/src.conf
# KERNCONF=GENERIC GENERIC-NODEBUG
KERNCONF=GENERIC-NODEBUG
%
  • without quotation marks.
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.
 
… 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?

Code:
$ file /usr/src/sys/amd64/conf/GENERIC-NODEBUG
/usr/src/sys/amd64/conf/GENERIC-NODEBUG: ASCII text
$
 
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.

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

FreeBSD Main
Code:
# 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
 
If you look at the GENERIC kernconf for 13-STABLE you will notice all the debug features are removed.



FreeBSD Main


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

Code:
% 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.

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