Embedded Linux Size Reduction: A Practical Guide
This guide explains how to reduce the size of an embedded Linux system, covering the main techniques from kernel trimming to filesystem choices. You will learn what actually saves space, what the trade-offs are, and how to apply these methods to your own project.
Why Size Matters in Embedded Linux
Embedded devices often have limited flash storage—anywhere from 4 MB to 512 MB—and every megabyte saved reduces BOM cost, boot time, and power consumption. Smaller images also fit into cheaper NOR flash or allow more room for user data. The goal is to remove unused components without breaking functionality, which requires a systematic approach rather than random deletions.
Start with the Kernel
The kernel is the largest single binary, typically 3–10 MB uncompressed. The most effective technique is to build only the drivers and features you actually need. Use make menuconfig to disable modules you do not use, such as unused filesystems, network protocols, or sound drivers. Compile drivers as modules only if they are loaded at runtime; otherwise, build them in to avoid module loading overhead. Also consider:
- Disabling kernel debug options (CONFIG_DEBUG_INFO, CONFIG_KALLSYMS) can save several megabytes.
- Using a custom kernel config based on your hardware, not a generic distro config.
- Compressing the kernel with LZ4 or XZ instead of GZIP—XZ gives better compression, LZ4 is faster to decompress.
Trim the Root Filesystem
The root filesystem often contains far more than needed. Start by listing the largest files and directories with du -x -h / | sort -h. Common space hogs include documentation, man pages, locale data, and static libraries. Remove them with:
- Deleting
/usr/share/doc,/usr/share/man, and/usr/share/info. - Keeping only required locales (e.g.,
en_US.UTF-8) and removing others. - Using
stripon binaries and libraries to remove symbol tables. - Replacing glibc with musl or uClibc-ng, which are significantly smaller.
Choose a Smaller C Library
glibc is the default on most desktop distributions but is heavy. musl is a lightweight libc that is drop-in compatible for most applications and can reduce the base system size by 1–2 MB. uClibc-ng is another option, but it requires recompiling all software. If you have control over the toolchain, using musl is the simplest way to shrink the base without changing application code.
Use BusyBox and Toybox
BusyBox combines hundreds of common Unix utilities into a single binary, saving several megabytes compared to separate coreutils, util-linux, and other packages. It is configurable—you can enable only the applets you need. Toybox is a similar project with a focus on simplicity and is used by Android. Both are designed for embedded use and are well-tested.
Optimize the Filesystem and Compression
The filesystem choice affects both size and performance. SquashFS is a read-only compressed filesystem that is ideal for the root partition—it compresses the entire filesystem and is mountable directly. For writable areas, use a small JFFS2 or UBIFS partition. Alternatively, you can use a compressed initramfs (e.g., initramfs.cpio.xz) for early boot, but note that it is decompressed into RAM. For production, SquashFS is usually the best balance of size and reliability.
Common Mistakes and Pitfalls
One frequent mistake is stripping the kernel of needed drivers, leading to boot failures. Always test on real hardware, not just QEMU. Another is forgetting to remove unused kernel modules from the filesystem—even if you build them as modules, they are stored in /lib/modules and take space. Also, be careful with locale and timezone data; they can add several megabytes. Finally, do not forget the bootloader: U-Boot can be configured to skip unused features and reduce its size.
Measuring and Verifying Size Reduction
Track your progress by recording the size of the kernel image, the root filesystem, and the final flash image after each change. Use size on binaries, du on directories, and ls -l on images. A typical reduction from a generic distro to a custom embedded system can be from 200 MB down to 10–20 MB. Always verify that the system boots and all required functionality works after each change.
Frequently Asked Questions
How much can I realistically reduce the size?
Depending on the starting point, you can often reduce the image by 80–95%. A full desktop distribution might be 1 GB, while a minimal embedded system for the same hardware can be under 10 MB. The exact figure depends on how many features you can remove.
Is it better to use a smaller libc or just strip binaries?
Stripping binaries saves a few hundred KB, but switching from glibc to musl can save 1–2 MB on the base system and also reduces runtime memory. If you can recompile, musl is more effective. If not, stripping and removing files is still worthwhile.
Can I use a compressed initramfs instead of a root filesystem?
Yes, but the initramfs is decompressed into RAM, so it uses more memory. It is useful for early boot or rescue systems, but for a production device with flash storage, a compressed read-only filesystem like SquashFS is more efficient.
What is the smallest possible Linux system?
There are examples of Linux systems that boot in under 2 MB, but they are extremely minimal and often lack standard utilities. For practical purposes, a 5–10 MB system with BusyBox, musl, and a minimal kernel is achievable for many embedded applications.
Does reducing size affect performance?
Usually not, because you are removing unused code. However, some optimizations like using XZ compression for the kernel or filesystem can slightly increase CPU usage during decompression. On slow processors, you might prefer LZ4 for faster boot.
How do I know which kernel drivers to remove?
Start with the hardware you have, then check which drivers are loaded at runtime with lsmod and dmesg. Remove drivers for hardware you do not have, and disable features like IPv6 or USB if not needed. Test each change on the target hardware.
Related
Method: the standard formula for this calculation, rounded as each result states. See how the calculators work or report an error.