You swap out a NIC or migrate a VM to new virtual hardware, and suddenly your boot logs are littered with warnings about dead modules. Most people ignore these because the system boots anyway, but leaving stale modules in initramfs is just asking for a cryptic panic during a kernel update. It bit me hard when a legacy RAID controller driver started fighting with a newer NVMe interface because the kernel was trying to init both during the early boot phase.

Why the kernel keeps ghosts in the machine

The kernel tries to be helpful by pulling in everything it thinks it needs based on udev events or older configurations. When you update your kernel package, dracut or mkinitcpio often just copies the current modules into the new image. If that configuration is dirty, you are carrying technical debt into your next production boot. You need to verify what is actually necessary before the next update hits.

lsmod | grep -v 'Used by' | awk '{print $1}' > /etc/dracut.conf.d/drivers.conf

• Check /etc/modules for hardcoded entries that might be obsolete
• Use lsinitrd to inspect the contents of your current initramfs image
• Verify if your vendor-specific kernel modules are still signed and supported
• Prune modprobe.d files that define aliases for hardware you decommissioned months ago

If you are strictly using a single hardware profile, you can force your initramfs generator to only include modules currently in use. Don’t do this on a fleet of heterogeneous bare metal servers unless you enjoy waking up to unbootable systems. But for consistent VM images or specialized appliance nodes, it is the only way to keep that boot path lean and predictable. Next time you pull hardware, check your boot logs before the next dist-upgrade forces a kernel rebuild.