Linux 7.3 on Fedora: Why Kernel, Modules, and Initramfs Must Match

Compiling Linux 7.3 produces a kernel image, but that image is only one part of a bootable Fedora installation. On a typical Fedora system, boot also depends on kernel modules, an initramfs assembled for the correct release, and a boot entry pointing to those artifacts. A mismatch can leave a perfectly compiled kernel unable to mount its root filesystem.

This matters when using the upstream source from kernel.org rather than Fedora’s kernel RPMs. Fedora’s package installation normally coordinates several boot artifacts. A manual upstream build leaves that coordination to the administrator. The example below assumes an ordinary x86_64 Fedora installation managed with GRUB and grubby, not an rpm-ostree-based desktop.

The kernel release connects three different locations

The release reported by make -s kernelrelease determines the installed module directory. It must agree with the release embedded in the kernel image and with the kernel version passed to dracut.

With a -fedora-local suffix, an example build identifies itself as 7.3.0-fedora-local:

/boot/vmlinuz-7.3.0-fedora-local
/usr/lib/modules/7.3.0-fedora-local/
/boot/initramfs-7.3.0-fedora-local.img
    |
    +-- Fedora boot entry references the image and initramfs

On Fedora, /lib/modules generally resolves to the same module location under /usr/lib/modules. The release string is an identity boundary, not a cosmetic filename. modprobe looks for modules associated with the running release, while dracut needs the corresponding installed modules when constructing early userspace.

Reusing a release string across different builds can overwrite the module tree for an existing custom kernel. A unique local suffix also keeps the manually built kernel distinct from Fedora’s packaged kernels. The Linux kernel build documentation explicitly recommends retaining a working kernel and using LOCALVERSION to distinguish builds.

Fedora’s configuration is a starting point, not a portable build manifest

Copying /boot/config-$(uname -r) preserves many decisions about hardware support, filesystem drivers, and loadable modules. It does not supply Fedora’s downstream patches or files referenced by distribution-specific configuration values.

For a Linux 7.3 source archive on x86_64, a representative preparation is:

sudo dnf install -y \
  gcc make bc bison flex binutils \
  elfutils-libelf-devel openssl-devel dwarves \
  ncurses-devel perl python3 xz zstd wget tar \
  dracut grubby mokutil

mkdir -p ~/kernel-build
cd ~/kernel-build
wget https://cdn.kernel.org/pub/linux/kernel/v7.x/linux-7.3.tar.xz
tar -xf linux-7.3.tar.xz
cd linux-7.3

cp "/boot/config-$(uname -r)" .config
printf '%s\n' '-fedora-local' > localversion
./scripts/config --file .config --set-str SYSTEM_TRUSTED_KEYS ""
./scripts/config --file .config --set-str SYSTEM_REVOCATION_KEYS ""
make olddefconfig
make -s kernelrelease

The two scripts/config calls remove paths to additional trusted or revoked certificate bundles that may exist in a Fedora source package but not in a vanilla kernel tarball. They do not sign the kernel or establish trust for Secure Boot. Other configuration-dependent build requirements may still need attention, including toolchains for enabled optional features.

make olddefconfig resolves new configuration symbols to their defaults without interactive prompts. Inspect its resulting .config before relying on the build for unfamiliar storage, encryption, or hardware configurations. The version printed by make -s kernelrelease is the value to use for every installation command that follows.

The compiled image and installed modules are separate outputs

A normal user can compile the kernel; elevated privileges are needed only when writing to system installation locations.

make -j"$(nproc)"
sudo make modules_install
KREL=$(make -s kernelrelease)

Parallel compilation can consume substantial RAM and disk space. Reduce the job count, for example to -j4, if the machine runs out of memory.

make modules_install places loadable modules under /lib/modules/$KREL. It does not by itself install arch/x86/boot/bzImage as the next bootable kernel. Copy the image and the files needed to inspect its build configuration:

sudo install -m 0644 arch/x86/boot/bzImage "/boot/vmlinuz-$KREL"
sudo install -m 0644 System.map "/boot/System.map-$KREL"
sudo install -m 0644 .config "/boot/config-$KREL"

System.map and the saved configuration help with later diagnostics; the compressed kernel image is what the bootloader loads. Kernel modules must come from the same build. A module compiled for a different release may fail to load because the module version information or kernel interfaces do not agree.

Dracut must target the new release, not the currently running one

Running plain dracut --force before reboot generally targets the currently running kernel. That would regenerate the old kernel’s initramfs, leaving the Linux 7.3 image without the early userspace intended for it.

Specify the new release explicitly:

sudo dracut --force "/boot/initramfs-$KREL.img" "$KREL"
ls -lh "/boot/vmlinuz-$KREL" "/boot/initramfs-$KREL.img"

dracut reads the modules installed for $KREL and assembles an initramfs with the functionality needed during early boot. Disk controller, filesystem, encryption, and volume-management support may be required before the real root filesystem becomes accessible. A missing driver can cause an emergency shell even when the kernel itself loaded successfully.

An initramfs built in host-only mode reflects the current machine’s storage environment. Moving the disk to different hardware may require regenerating a less hardware-specific image. Fedora’s dracut documentation describes why the target kernel version matters.

A boot entry must point to the matching pair

Copying bzImage into /boot does not guarantee that GRUB has an entry for it. Fedora installations using boot loader specification entries can use grubby to register the manually installed kernel while carrying over the default entry’s root and kernel command-line arguments:

sudo grubby \
  --add-kernel="/boot/vmlinuz-$KREL" \
  --initrd="/boot/initramfs-$KREL.img" \
  --title="Fedora Linux $KREL" \
  --copy-default

sudo grubby --info="/boot/vmlinuz-$KREL"

--copy-default copies applicable settings from the default entry, not the old kernel image or initramfs paths. This is important on Fedora installations that use a filesystem UUID, encrypted root, or other boot parameters. Check the generated entry instead of assuming those parameters are interchangeable between machines.

Do not immediately change the default kernel. Select the new entry from the boot menu for the first test, keeping the distribution kernel available as a fallback. After a successful boot, verify the running identity and inspect kernel messages:

uname -r
journalctl -b -k -p warning
sudo grubby --info=ALL

A successful uname -r match verifies which kernel started. It does not prove every driver works, so storage, networking, graphics, suspend, and out-of-tree modules still deserve testing.

Secure Boot and recovery are independent boundaries

On UEFI systems, check the current policy before rebooting into an unsigned build:

mokutil --sb-state

When Secure Boot is enabled, the boot chain may reject an unsigned custom kernel. Signing the kernel for a trusted key and enrolling that key through the appropriate MOK process is separate from compilation. Kernel module signature enforcement may introduce a second trust requirement for loadable drivers. Clearing SYSTEM_TRUSTED_KEYS does not bypass either check; the kernel module-signing documentation covers the relevant trust configuration.

Failure symptoms expose different boundaries:

A kernel installed this way is not an RPM owned by dnf. Normal Fedora kernel updates do not maintain or remove its manually installed boot files. Preserve a known-good Fedora boot entry and its module directory until the custom build has passed real workload testing; that fallback is what makes a failed upstream-kernel experiment recoverable.