Most recent amd64 minimal image is 58MB ("Artful Aardvark").
Trusty Tahr bzImage compressed kernel is 5.5MB.
The initrd.cpio.gz is 20MB.
The uncompressed initrd is 52MB.
Assuming most of the initrd size is modules, can the Linux user reduce the size of the initrd by compiling own kernel and creating own initrd with only the modules she needs?
If you really do need a kernel, and the few extra MB required by modules is a problem, you should probably be using Buildroot or Yocto for your bootloader/kernel.
These things are a full OS installer ie put it on a USB key, CDROM, PXE boot or whatever. These are a minimal installer and not a minimal installation, although that is a side effect - you don't get much out of the box but you can add everything later.
You could, for example, do a minimal install and then do "# apt install libreoffice" and with luck (not too sure) get the whole lot - X etc - to run it. You might have to add a Window Manager and a few other things.
Also worth noting:these images are full minimal root filesystems. "installer" images refer to the images containing software --the debian/ubuntu installer for bootstrapping a root filesystem onto a mounted volume. The minimal images from thearticle do not contain this installer, and are stanalone root filesystems.
The installs the OP is talking about are images that don't even have a kernel, and don't use the traditional installer.
These things are loaded on every boot, which needs to be fast. That includes both the time to load them into RAM and to decompress them, and it's possible that gzip still wins on that.
Personally, I keep my initrd uncompressed because I've found that on my SSD loading that is faster than loading any compressed version + decompressing it, but that doesn't hold for spinning rust.
It’s why lz4 compression of a file system can be faster than no compression even with an ssd on fast machines; I wonder if that would boost your performance vs the uncompressed image (though I don’t know if the kernel supports lz4 decimal at boot time)?
Doesn't have to be. You could also load it from HDD, which is probably rather common when we're talking about containers and such (and in other circumstances, the couple of MB you'd save here with xz hardly matter). Also there's this PXE thing that I don't understand.
> I wonder if that would boost your performance vs the uncompressed image (though I don’t know if the kernel supports lz4 decimal at boot time)?
It didn't last time I checked, but it seems like it does now. So I'll give that a go.
Though I did figure out that for some reason my system was running "lvm2-monitor.service", which took 1s all by itself for doing absolutely nothing (don't use lvm). So I masked that and gained more time than any compression method could.