Building A Custom Kernel From Source On Fedora

Compiling a Linux kernel lets you test new hardware support, enable a feature missing from Fedora’s standard build, or create a lean kernel for a specialised server. It is an excellent learning exercise, but the process changes core operating-system components, so a reliable fallback kernel must remain installed.

Fedora already provides a well-tested kernel through its package repositories. A custom build is therefore best treated as a separate, clearly named experiment. Test it first on a spare workstation or virtual machine before using it on a production host in a Sydney, Melbourne, or Perth data centre.

Decide What The Custom Kernel Should Solve

Begin with a specific objective. You might need a driver for a new storage controller, a filesystem option, real-time scheduling, improved virtualisation support, or a configuration suitable for a small home lab. Without a defined goal, it is easy to create a kernel that is harder to maintain without offering a useful benefit.

Check the running system and Fedora release before changing anything:

cat /etc/fedora-release
uname -r
lscpu
lsblk

Keep the stock Fedora kernel available in the boot menu. It provides a recovery path if the new kernel fails to detect networking, storage, graphics, or other essential hardware.

Install The Build Environment

Update package metadata and install the compiler, kernel development tools, and libraries commonly required by the build:

sudo dnf upgrade --refresh
sudo dnf group install "Development Tools"
sudo dnf install ncurses-devel bison flex elfutils-libelf-devel \
  openssl-devel bc rsync dwarves perl-generators rpm-build

A full kernel compilation can consume several gigabytes of disk space and considerable CPU time. On an NBN connection, downloading source archives is usually straightforward, but upload bandwidth can be much slower, so avoid planning remote transfers of large build trees during a maintenance window.

Create a workspace with ordinary user permissions:

mkdir -p ~/kernel-build
cd ~/kernel-build

Do not build as root. Root access is needed for installation, not for compiling source code.

Download And Prepare The Source

Obtain a kernel release from kernel.org or use Fedora’s source package when you need Fedora-specific patches. For a mainline release, download and unpack the archive, then enter its directory:

curl -LO https://cdn.kernel.org/pub/linux/kernel/v6.x/linux-6.12.10.tar.xz
tar -xf linux-6.12.10.tar.xz
cd linux-6.12.10

Replace the version with the release you have selected. Verify a downloaded archive with its published checksum where possible. The kernel source tree should be kept separate from Fedora’s packaged kernel files, making it easier to remove or rebuild later.

Copy the configuration used by the running kernel:

cp /boot/config-$(uname -r) .config
make olddefconfig

olddefconfig accepts existing settings and selects defaults for options introduced in the newer source. This is safer than starting from an empty configuration, especially on hardware with unusual storage or network devices.

Configure Required Features

Use the menu-driven configuration interface when you need to change options:

make menuconfig

Kernel settings are grouped into areas such as General Setup, Processor Type, Device Drivers, Networking Support, Filesystems, and Security. Press / inside the menu to search for an option. Keep essential disk, filesystem, storage-controller, and network-driver support built in or available as modules.

Give the build a recognisable suffix so it is easy to identify during boot:

scripts/config --set-str CONFIG_LOCALVERSION "-custom"

If scripts/config is unavailable in the selected source tree, set CONFIG_LOCALVERSION through make menuconfig. Review the final configuration with grep CONFIG_LOCALVERSION .config. For a web server or LAMP test host, you can document the configuration alongside the system notes used for your Fedora LAMP setup.

Compile The Kernel And Modules

Start the build using the available processor threads:

make -j"$(nproc)"

Compilation time varies with CPU, memory, and storage speed. A modern desktop in Melbourne may finish quickly, while a small VPS in an Australian cloud region can take substantially longer and may have strict CPU-credit limits. Monitor disk space with df -h and avoid compiling on a nearly full root filesystem.

If the build stops with a missing header or utility, read the last error rather than rerunning blindly. Install the relevant Fedora package, then repeat the command. A failed build normally leaves usable intermediate files, so it does not always need to start from the beginning.

Install And Boot Safely

Install the modules and kernel from the source directory:

sudo make modules_install
sudo make install

Fedora normally uses dracut to create an initramfs and grubby to maintain bootloader entries. Check that the new files and menu entry exist:

ls -l /boot
sudo grubby --info=ALL | less

Regenerate the initramfs manually if necessary:

sudo dracut --force

Reboot during an agreed maintenance period. This matters for businesses operating on Australian Eastern Standard Time, particularly when staff in Brisbane, Sydney, and Melbourne share the same service window while Perth teams work several hours behind.

At the boot menu, select the custom kernel and keep the Fedora kernel as the default fallback until testing is complete. If the machine cannot start correctly, reboot and select the older entry rather than repeatedly attempting the failed build.

Verify Hardware And System Behaviour

After booting, confirm the running release:

uname -a
cat /proc/cmdline
systemctl --failed

Check networking, storage, mounted filesystems, audio or graphics, containers, and any application that motivated the kernel change. Review warnings with:

journalctl -k -b
dmesg --level=err,warn

For a server hosted near Sydney or Melbourne, test real application traffic and latency from the locations your users actually occupy. For a Perth office or remote site, compare network behaviour separately; an apparently successful kernel test on a local workstation does not prove that a production workload will behave identically.

Maintain, Remove, And Rebuild

Record the source version, configuration changes, compiler version, and reason for the custom build. A kernel compiled today will not automatically receive Fedora security updates. You must monitor upstream advisories, rebuild when required, and repeat testing after each source update.

To remove an unused custom kernel, first boot another kernel and identify its installed package or files. Avoid deleting the active kernel. On systems installed with Fedora packaging tools, package-managed files can be inspected with rpm -qa | grep kernel; manually installed files under /boot should be handled carefully and matched with their module directory under /lib/modules.

A custom kernel is successful when it solves a defined requirement and remains recoverable, documented, and supportable. Keep the standard Fedora kernel, verify the boot entry, and remember that careful configuration matters more than simply producing a successful compilation.