Comment 5 for bug 1490115

"I don't understand the disconnect here. The only reason for putting kernel
modules in an initramfs is if they're needed to access the rootfs."

correct, except this should read "any rootfs" ... we ship all possible filesystem modules as well as all network card modules (for possible netboot) etc ... there is a lot more in a -generic initrd than you need today (my amd64 initrd here shrinks from 19M to 5.8M if i remove the modules)

note that i'm not proposing this change for non snappy installs where we actually might want the ability to boot any kind of any generic rootfs.

on snappy we have a predefined partition and filesystem setup, with all needed filesystems already in the kernel by default. porters with own kernels currently have to open the initrd and replace or remove the modules to get a sane sized file without (for them) useless bloat.
on the phone where we have a similar situation we produce a fully generic binary initrd from a deb package (without any modules) which massively reduces size and maintenance cost (and support for ports that have breakage due to the porter manually tinkering with the initrd).

we could indeed go with a completely module-less initrd for the above, the module.img approach only comes into play if we ever want to offer netboot installs or early access to specific hardware (security hardware for decrypting an encrypted writeable partition during boot comes to mind here) without making the initrd non-generic.

additionally the img format for /lib/modules makes deployment inside a snap a lot easier (you only need to verify the checksum of a single file against the store etc).

the modules.img bit is not cruical for this bug and should probably be a separate wishlist bug, the main focus here should be on producing an actually generic initrd binary that is re-usable everywhere without modification and optimized for size and boot speed.