3 ms·

Not a Linux user but out of curiosity just looked at the "Trusty Tahr" 37MB amd64 minimal image (mini.iso). Most recent amd64 minimal image is 58MB ("Artful Aa

Not a Linux user but out of curiosity just looked at the "Trusty Tahr" 37MB amd64 minimal image (mini.iso). 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?

subway 9y ago
Or just ditch the kernel and initrd entirely. If you're trying to save a few MB on an Ubuntu image, you're almost certainly working in a container environment where you don't need a kernel inside the fs. 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.
- gerdesj 9y ago
  I don't think everyone is working within a container when they boot a Ubuntu minimal, unless your containers happen to have a BIOS or similar. 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.
  - subway 9y ago
    I agree -- there are plenty of reasons to use a minimal Ubuntu install. My point was that if size constraints are so tight that you feel trimming kernel modules out is a reasonable use of effort, then Ubuntu starts to be a more awkward fit. If you constantly have to trim away bits left by the package manager (man pages, examples, extra kernel modules), your time is probably better spent with a distro that allows you to avoid ever laying those into the rootfs to begin with. 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.
    - secabeen 9y ago
      Yeah. To be more clear, you can install a "minimal" system of Ubuntu on bare metal by just installing the "required" packages only, although I think the default if you don't select any tasks in the installer is to install "required" + "standard", which is a small amount more than just "required". Either way, it doesn't include much. I have to install openssh-server on my "nothing-but-standard" systems, before chef comes in and drags along another 1000 packages. The installs the OP is talking about are images that don't even have a kernel, and don't use the traditional installer.
ComputerGuru 9y ago
Curious. Why gzip and not xz?
- faho 9y ago
  Faster decompression. 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.
  - ComputerGuru 9y ago
    Sure, but this is the installer presumably being loaded from CD/USB; in addition to not needing to be compressed the same as the resulting installation and being a one-time ordeal, these are slower media: the less you have to read from disk, the faster your end result may be, even including decompression time. 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)?
    - faho 9y ago
      >Sure, but this is the installer presumably being loaded from CD/USB 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.
      - faho 9y ago
        Turns out it's a wash. On my arch machine the uncompressed image is 27M, with lz4 it's 14M. Both take around 10s to desktop according to `systemd-analyze` (which includes 3s bootloader timeout). 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.

subway 9y ago

Or just ditch the kernel and initrd entirely. If you're trying to save a few MB on an Ubuntu image, you're almost certainly working in a container environment where you don't need a kernel inside the fs. 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.

gerdesj 9y ago
I don't think everyone is working within a container when they boot a Ubuntu minimal, unless your containers happen to have a BIOS or similar. 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.
- subway 9y ago
  I agree -- there are plenty of reasons to use a minimal Ubuntu install. My point was that if size constraints are so tight that you feel trimming kernel modules out is a reasonable use of effort, then Ubuntu starts to be a more awkward fit. If you constantly have to trim away bits left by the package manager (man pages, examples, extra kernel modules), your time is probably better spent with a distro that allows you to avoid ever laying those into the rootfs to begin with. 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.
  - secabeen 9y ago
    Yeah. To be more clear, you can install a "minimal" system of Ubuntu on bare metal by just installing the "required" packages only, although I think the default if you don't select any tasks in the installer is to install "required" + "standard", which is a small amount more than just "required". Either way, it doesn't include much. I have to install openssh-server on my "nothing-but-standard" systems, before chef comes in and drags along another 1000 packages. The installs the OP is talking about are images that don't even have a kernel, and don't use the traditional installer.

ComputerGuru 9y ago

Curious. Why gzip and not xz?

faho 9y ago
Faster decompression. 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.
- ComputerGuru 9y ago
  Sure, but this is the installer presumably being loaded from CD/USB; in addition to not needing to be compressed the same as the resulting installation and being a one-time ordeal, these are slower media: the less you have to read from disk, the faster your end result may be, even including decompression time. 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)?
  - faho 9y ago
    >Sure, but this is the installer presumably being loaded from CD/USB 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.
    - faho 9y ago
      Turns out it's a wash. On my arch machine the uncompressed image is 27M, with lz4 it's 14M. Both take around 10s to desktop according to `systemd-analyze` (which includes 3s bootloader timeout). 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.