Set modules=dep in (https://manpages.debian.org/jessie/initramfs-tools/initramfs...) and run update-initramfs.

I doubt that'll affect boot time but it reduces initrd.img size a lot.

maybe not on an SSD but it definitely helps a lot on HDD by virtue of having far less disk traffic. The kernel's method for figuring out which modules to load is effectively to load every single module that might be compatible with a given device in series and then ask the module for its opinion before unloading it, and then once it has a list of all (self-reported) compatible modules for a given device it picks one and reloads it.

> helps a lot on HDD by virtue of having far less disk traffic

Still doesn't matter because we're talking about init ramdisk here. It's a sequential file loaded into RAM before the kernel. Whether it's 5MB or 20MB would't matter much even on a hard drive. After that it's all in RAM anyway.

Why does it not cache that list for next boot? On hardware changes one could add a boot flag to invalidate the cache.

That may not make sense for all installs, but for power user installs I think it would make sense.

For anything involved in the I/O stack this would be a complete non-starter because having a cache implies the existence of a filesystem which in turn implies the existence of all underlying modules. PCI, network stack, USB, etc can all be necessary prerequisites for that so it's a non-starter for anything involved with them too; at this point we've already ruled out most of the computer.

Also for embedded systems there often isn't a writable filesystem, and that is a huge part of linux's userbase.

Thank you. I'll spend some time to learn why that is not the default config setting.

IDK; at the time i was using gentoo, in which it's natural not to have more modules than necessary because part of the installation process involves generating your own kernel configuration.

Even though it's not the normal way to install debian there ought to be some sort of way to build your own custom kernels and modules without interferance from the package manager (or you can just run it all manually and hope that you dont end up in a conflict with apt). Gentoo is the only distro where it's mandatory but im pretty sure this is supported on just about every distribution since it would be necessary for maintainers.

Every time I hear about gentoo I am torn between the "I should really be doing that" mindset and the "I don't have time for that" mindset.

Surprisingly enough the hardest part about gentoo is actually not the kernel but the userspace. Every package has these "use flags" and "keyword flags" which can control compile-time options and that seems fine enough on its own until you get to the point where you have multiple packages all sharing a dependency with mutually-exclusive USE flags and it's entirely up to you to figure out how to untangle this mess in a way that every package's dependencies are satisfied.