Build a custom Linux kernel on Fedora
Fedora’s packaged kernel suits most systems. Building from source is useful when a driver, security option or hardware behaviour must change before Fedora supplies a package. It also exposes the configuration and modules entering an appliance.
Australian organisations often run production workloads on RHEL-compatible platforms because procurement favours long-lived releases, while Fedora serves as the upstream proving ground. Repeatable builds are valuable for drivers and specialised hardware.
Before changing a working machine, document its kernel release, firmware, bootloader and modules. A quick arvo sanity check around Melbourne or Brisbane can catch missing disk space, a locked package transaction or a firmware change. Keep a spare system or virtual machine for destructive tests.
The finished image must work with Fedora’s initramfs, dracut, Secure Boot and GRUB. Treat these integrations as part of the build. A successful compile proves only that source can be transformed; dependable operation requires a controlled reboot and hardware checks.
Prepare the Fedora build host
Install the required toolchain on an up-to-date Fedora workstation. Before replacing packages, review dnf history and rollback to understand recent changes and restore a known-good dependency set if needed. Record the baseline kernel.
Install the compiler, build utilities, headers and source package, then check disk space:
sudo dnf install gcc make git kernel-devel kernel-source rpm-build perl flex bison elfutils-libelf-devel openssl-devel dwarves bc dracut grub2-tools
uname -r
rpm -q kernel kernel-devel kernel-source
df -h /boot
Build as a normal user in a dedicated directory. The kernel-source package combines Fedora configuration and downstream patches, which matters for module, firmware and initramfs compatibility. Locate and copy the matching tree:
mkdir -p ~/kernel-builds
cp -a /usr/src/kernels/$(uname -r) ~/kernel-builds/fedora-custom
cd ~/kernel-builds/fedora-custom
Use rpm -ql kernel-source if the source path differs on your Fedora release.
Select and configure the kernel source
Fedora’s source RPM carries Red Hat patches, security fixes and packaging assumptions. Upstream Git exposes newer mainline code but leaves you responsible for reconciling Fedora changes. This choice shapes maintenance more than the compile command.
For upstream, clone Torvalds’ repository, select a stable tag and record git log -1 --oneline. Keep full history if later rebases or vendor patches are likely. For Fedora, use the copied tree unless you have a specific upstream patch to test.
Kconfig exposes switches for version strings, filesystems, drivers and debugging. Set CONFIG_LOCALVERSION through make menuconfig, save .config, and avoid features you cannot maintain:
make menuconfig
make olddefconfig
cp .config ../fedora-custom.config
Compile the kernel and modules
Match build parallelism to available memory. On a small virtual machine, make -j4 may be more reliable than using every reported CPU:
make -j"$(nproc)"
The build produces bzImage, kernel objects, modules and optional BTF metadata. Leave several gigabytes free for intermediate files, module installation and the initramfs, and retain the build directory until validation completes.
Fedora configurations commonly require pahole for BTF, supplied by the dwarves package. Compiler, binutils and kernel-header mismatches also cause failures, so fix the first compiler error instead of changing several options at once.
Install and validate the kernel
Install only after a clean build. The targets copy artefacts into /lib/modules and /boot, run dracut to generate the initramfs and create a Boot Loader Specification entry for GRUB.
sudo make modules_install
sudo make install
Reboot into the new entry and confirm that the running release, module tree and initramfs agree. Keep the previous kernel as a fallback, and use the serial console or journal if the graphical boot fails.
uname -r
dmesg -T
modinfo drivetrain
lsinitrd /boot/initramfs-$(uname -r).img
Secure Boot may reject an unsigned local image. Use an approved signing process, or disable enforcement only on an isolated test machine. Cloud regions such as AWS ap-southeast-2 in Sydney or Microsoft Azure Australia East may restrict kernel replacement, so check provider policy. Legacy DOS is another boundary: the DOS4GW archive documents a 32-bit extender for an emulator or disposable VM, not a production host.
Compare kernel build approaches
Each source route changes the balance between convenience, patch coverage and control. Choose an operating model before selecting commands.
| Approach | Patch and configuration coverage | Best fit | Main cost |
|---|---|---|---|
| Packaged Fedora kernel | Tested patches and defaults | Daily workstation and server use | Little customisation |
| Fedora source build | Distribution patches and configuration | Local drivers and controlled tuning | Manual rebuilds |
| Upstream Git build | Mainline code without distro patches | Testing newer features | Patch and support work |
| Isolated build | Chosen source inside a VM or CI worker | Repeatable jobs | Build infrastructure |
The Fedora source route is usually the least disruptive for a local driver or configuration change. Upstream offers earlier features and clearer code provenance, yet transfers patch auditing and configuration responsibility to the builder. A packaged kernel remains preferable when the required functionality already exists.
Deployment recommendations and final reminders
Treat the custom image as a controlled deployment. These checks make maintenance and incident response predictable.
- Snapshot virtual-machine storage or use a spare machine before changing boot artefacts.
- Keep rescue media, the previous kernel and its matching initramfs available.
- Archive the source revision,
.config, patches, module list and build log. - Test storage, networking, Wi-Fi, suspend and Secure Boot, plus
Australia/BrisbaneandAustralia/Sydneytime handling around daylight-saving changes. - Schedule rebuilds for security updates and define what triggers a new image.
For teams supporting Australian customers, a custom build may target Fedora hardware while production runs on RHEL-compatible platforms or in cloud regions. Document kernel and module compatibility across that boundary; do not assume Fedora’s shorter support cycle applies to the enterprise service.
The result should be a reproducible artefact whose source revision, configuration, modules, firmware, initramfs and boot entry are all accounted for. Remember that a successful compile only proves code generation; operational success means the machine boots reliably, loads the intended modules, keeps correct time and remains supportable after the next update.