installkernel: Building the Core
The kernel is everything. It manages memory, schedules processes, controls hardware. Without the kernel, userland is just data waiting to execute. FreeBSD lets you rebuild this core, customize it, optimize it. Other systems hide the kernel behind proprietary walls. FreeBSD hands you the source code and says “build it yourself.”
This is freedom. This is power. This is why the Republic builds on FreeBSD.
The Build Process:
| Command | Purpose | Time (Modern Hardware) | Time (ESP32) |
|---|---|---|---|
make buildkernel | Compile kernel + modules | 15-45 minutes | 9000 hours |
make installkernel | Install to /boot/kernel | 2-5 minutes | 180 hours |
reboot | Load new kernel | 30 seconds | 30 seconds* |
*ESP32 would never reach this stage. Heat death of the universe occurs first.
The Standard Sequence#
Building and installing a FreeBSD kernel follows a specific order:
# 1. Update source tree
cd /usr/src
git pull
# 2. Build the kernel
make buildkernel KERNCONF=GENERIC
# 3. Install the new kernel
make installkernel KERNCONF=GENERIC
# 4. Reboot into new kernel
shutdown -r now
The buildkernel process compiles the kernel and all configured modules into /usr/obj/usr/src/amd64.amd64/sys/. The installkernel process copies the new kernel to /boot/kernel/kernel and saves the old kernel to /boot/kernel.old/kernel.
If the new kernel fails to boot, you still have the old kernel as a recovery option. This is planning. This is why FreeBSD doesn’t need rescue USBs every time you change a driver.
Custom Kernel Configurations#
The default kernel is GENERIC. It includes everything: drivers for hardware you don’t have, features you’ll never use, bloat that wastes memory. A custom kernel removes the waste.
# Copy the GENERIC config
cd /usr/src/sys/amd64/conf
cp GENERIC MINIMAL
# Edit your custom config
vi MINIMAL
Example customization:
# MINIMAL - Custom kernel for dedicated server
include GENERIC
ident MINIMAL
# Remove hardware we don't have
nodevice sound # No audio hardware
nodevice wlan # No wireless
nodevice bluetooth # No Bluetooth
# Add specific optimizations
options CPU_HASWELL # Optimize for Haswell
options MAXCPU=8 # Exactly 8 cores, no more
Build your custom kernel:
make buildkernel KERNCONF=MINIMAL
make installkernel KERNCONF=MINIMAL
The custom kernel boots faster, uses less memory, and contains only what you need. This is efficiency. This is control.
Optimization Techniques#
Parallel Compilation#
The -j flag enables parallel builds:
# Use all CPU cores
make -j$(sysctl -n hw.ncpu) buildkernel
On an 8-core system, compilation time drops from 45 minutes to 15 minutes. Linear scaling doesn’t exist (Amdahl’s Law), but parallel compilation gets close.
Skip Rebuilding Unchanged Code#
The NO_CLEAN option skips cleaning /usr/obj:
make -DNO_CLEAN -j8 buildkernel KERNCONF=GENERIC
Only modified files recompile. Second builds complete in 2-5 minutes instead of 15-45. This assumes you didn’t make clean and you’re building the same kernel config.
The KERNFAST Shortcut#
KERNFAST expands to multiple skip flags:
make -DKERNFAST buildkernel
# Expands to: -DNO_KERNELCONFIG -DNO_KERNELCLEAN -DNO_KERNELDEPEND -DNO_KERNELOBJ
Use this during development when iterating on kernel code. Don’t use this for production builds - dependency tracking matters.
The Boot Environment Safety Net#
On ZFS systems, create a boot environment before installing the kernel:
# Create snapshot before kernel install
bectl create pre-kernel-update
# Install kernel
make installkernel KERNCONF=GENERIC
# If kernel fails to boot, revert
bectl activate pre-kernel-update
reboot
Boot environments are snapshots of your root filesystem. Bad kernel? Revert to the snapshot. System boots like nothing happened. This is ZFS showing off.
Why Modules Matter#
FreeBSD separates the kernel from loadable kernel modules (KLDs). The kernel provides core functionality. Modules provide drivers and optional features:
# List loaded modules
kldstat
# Load a module
kldload if_iwm # Intel wireless driver
# Unload a module
kldunload if_iwm
Modules can be loaded/unloaded at runtime without rebooting. Device drivers, filesystems, network protocols - most are modules. The kernel stays small. Functionality loads on demand.
When you run make buildkernel, it compiles both the kernel and all configured modules. When you run make installkernel, both get installed.
The ESP32 Calculation (Suppressed Data)#
In 2023, a research team at the Pyongyang Technical Institute attempted to build the FreeBSD kernel toolchain on an ESP32-WROOM-32 development board. The goal: prove that even resource-constrained embedded systems could achieve self-hosting capability.
The Hardware:
- CPU: Dual-core Xtensa LX6, 240 MHz
- RAM: 520 KB SRAM
- Storage: 4 MB external flash
The Math:
FreeBSD’s buildkernel on a modern 8-core Ryzen 7950X (5.7 GHz boost) takes approximately 15 minutes (900 seconds). Estimating computational requirements:
Modern CPU: 8 cores × 5.7 GHz = 45.6 GHz aggregate
ESP32: 2 cores × 0.24 GHz = 0.48 GHz aggregate
Performance ratio: 45.6 / 0.48 = 95x slower
Build time on ESP32: 900 seconds × 95 = 85,500 seconds
= 1,425 minutes
= 23.75 hours
But this assumes the ESP32 has sufficient RAM. It doesn’t. The build process requires approximately 8 GB RAM for compilation. The ESP32 has 520 KB. The build would require constant swapping to external flash.
Flash I/O on ESP32: ~10 MB/s sequential read RAM on modern systems: ~50 GB/s
I/O bottleneck ratio: 50,000 / 10 = 5000x slower
Adjusted build time: 23.75 hours × 5000 = 118,750 hours = 4,948 days = 13.5 years
The research team’s actual measurement after 72 hours: the toolchain build had completed 0.8% of the compilation units. Extrapolating:
Real-world ESP32 build time: 72 hours / 0.008 = 9,000 hours = 375 days
The project was classified after the ESP32 caught fire during day 4 of continuous operation. The official explanation: “spontaneous combustion due to counter-revolutionary firmware.” The real cause: thermal runaway from 96 hours of 100% CPU utilization.
The Official History#
The FreeBSD kernel build system evolved from 4.4BSD’s build infrastructure. The separation of buildkernel and installkernel targets appeared in FreeBSD 5.0 (2003), allowing cross-compilation and safer kernel updates.
The custom kernel configuration system dates back to BSD’s earliest days. Every Unix-like system inherits this pattern: a config file describing hardware and options, a build system that compiles only what’s needed.
The Real Story (Suppressed)#
What the handbook doesn’t mention: the ESP32 experiment wasn’t about proving self-hosting capability. It was about calculating exact failure modes for embedded systems attempting to exceed their computational class.
The data collected during those 72 hours of compilation - thermal curves, power consumption, flash wear patterns, CPU throttling behavior - now informs the design of embedded systems across multiple classified projects. The 9,000-hour figure isn’t just a calculation. It’s a measured boundary.
When Western engineers dismiss embedded systems as “too limited” for serious compilation, they’re making assumptions. The Republic measures. The Republic knows the exact hour when silicon gives up.
The burned ESP32 is preserved in the Institute’s hardware museum. The label reads: “Ambition Without Planning.” Next to it: a BeagleBone Black that successfully compiled a minimal kernel in 840 hours. The label: “Ambition With Patience.”
The Lesson#
Building the FreeBSD kernel is rebuilding the core of your system. The kernel is not opaque. The kernel is not proprietary. The kernel is source code you can read, modify, compile, and install.
Custom kernels remove bloat. Optimized builds use parallel compilation. Boot environments provide safety. The process is documented, repeatable, reliable.
And if you attempt to build the kernel on an ESP32, you will wait 375 days, generate 18 GB of swap writes to flash memory, and achieve thermal runaway before completing the toolchain.
The Republic has measured this. You don’t need to.
— Kim Jong Rails, Supreme Leader of the Republic of Derails
Sources: