You spend an hour debugging a system that hangs right after the initramfs stage, only to realize the kernel tried to load a module that does not actually exist or is completely incompatible with your hardware. Most of us assume that if a module is requested by udev or modprobe, the system just handles the failure gracefully. It usually does, but sometimes it results in a kernel panic or a massive delay that makes you think the disk is dead.

Why modules hang the boot process

The kernel uses aliases to map hardware identifiers to specific drivers. When you have a massive module dependency list, udev tries to load everything it sees matching a pattern. If you have a driver that probes hardware by polling a register that happens to hang your bus, the entire boot process stalls. I once saw this happen because of an old, irrelevant sound driver that sat there waiting for a response from a device that hadn’t existed for three hardware generations.

echo install sound-driver /bin/false > /etc/modprobe.d/blacklist-custom.conf

• Use modprobe –show-depends to see what is actually triggering a chain of loads.
• Check /etc/modprobe.d/ to ensure you aren’t fighting against legacy driver configurations.
• Use the modprobe.blacklist parameter on your kernel cmdline for the quickest way to skip problematic modules without rebuilding the initrd.

If you are hitting this repeatedly, look at the kernel log immediately after the system comes back up. Use journalctl -k -b -1 to examine the previous boot, and look for those ominous gaps in timestamps. If you see a module load right before a long silence, that is your culprit. Don’t waste time looking for hardware errors until you’ve confirmed that the kernel isn’t just getting stuck in a loop trying to talk to a ghost device.