AUTHOR: Joachim Beckers DATE: 2005-07-31 LICENSE: GNU Free Documentation License version 1.2 SYNOPSIS: Tips and tricks for creating a small LFS system. PRIMARY URI: http://jbeckers.webhop.org/en/hints.html DESCRIPTION: A freshly built LFS system is relatively small, but still, in certain occasions, it can take up too much disk space. This hint provides some easy and more advanced tips and tricks to strip down an LFS system, so that it will fit on a smaller harddisk. PREREQUISITES: Since certain optimizations can only be done at build time, I strongly advise you to read the entire hint before you start building your LFS system, . This does not mean you can't use this hint to strip down an existing LFS system, but there might be some difficulties. Secondly I assume that readers of this hint have some experience with LFS and with Linux and its tools in general. And of course, as you will know for sure: make back-ups before you do anything potentially harmful to your system! HINT: Compile time optimizations: =========================== Building up a small LFS system already starts at compile time. The compiler and linker have some features that allow them to create smaller binaries/libraries. To make use of these features, adjust your CFLAGS. During the LFS build, this should be done when setting up the environment and right after entering chroot. There are discussions about which CFLAGS to use. The truth is that no one knows exactly. On top of that, every system is different and requires different optimizations. The best thing to do is to read up on compiler optimizations and decide for yourself. However, the most used and considered safe CFLAGS are: -Os, which tells the compiler to optimize for size, -fomit-frame-pointer, which turns of frame pointers (a debugging feature), -march=, which turns on cpu-specific optimizations, -pipe, which tells gcc not to create temporary files but pipe data. Use with caution, as it also makes gcc use more RAM. Not only CFLAGS can reduce the size of binaries. There are other way to accomplish the same result. Setting the environment variable CC to "gcc -s" will cause gcc to strip binaries as they are created. Setting LDFLAGS to "-s" will do the same thing for libraries. Notes: - A good starting point to learn about gcc and its options is this hint: http://www.linuxfromscratch.org/hints/downloads/files/optimization.txt - If you want the full reference, check out the online gcc docs: http://gcc.gnu.org/onlinedocs/ If you don't use NLS (a.k.a. locales), you can configure packages with --disable-nls to conserve some room. For the three largest packages in the LFS book (gcc, glibc and the kernel) there are plenty of ways to slim them down. Some compilers in the GNU Compiler Collection are very rarely used. If you think you don't need them, remove the sources before the build. e.g.: # rm -rf libjava libobjc gcc/ada gcc/f gcc/java gcc/objc The other big package, glibc, is a bit harder to strip down. You can start by adding "--enable-omitfp --enable-kernel=" as extra configure arguments. The former turns off frame pointers, while the latter disables code that is needed for compatibility with kernels older than your current kernel. After the build has finished, you can do: # rm libc_g.a The library libc_g.a contains debugging symbols and can safely be removed. Lastly, the kernel. The easiest way the create a small kernel is without any doubt, by excluding as much as possible from your kernel's configuration. Also, If you compile a keymap into the kernel, other keymaps can be removed later on. Run time optimizations: ======================= Stripping binaries and libraries can free a lot of space. Use the instructions provided in the LFS book to do this. To find out whether there are still unstripped libraries or binaries, run the following command: # find / -exec file {} \; | grep "not stripped" These can be stripped as well. Note: Do not strip any binary or library that's currently in use. It's possible that the program using it will crash. Compressing man and info pages is a second big win. For the most convenient way of compressing man and info pages, see the compressdoc.sh script that comes with the BLFS book. If you know all man and info pages by heart, you can remove them ;-). Other kinds of documentation (licenses, READMEs, ...) can safely be removed as well. If you have chosen to build all packages without support for locales, you can remove everything in /usr/share/locale and /usr/lib/locale. If you have chosen to compile your keymap into the kernel, the same applies for /usr/share/kbd. If you copy your timezone to /etc/localtime instead of making a symlink, all of /usr/share/zoneinfo can be removed as well. Extreme optimizations: ====================== As the title says, these are extreme optimizations that can easily break your system. They require extensive knowledge of the internals of a linux system. Use them at your own risk. Note: It's a good idea to take back-ups of your system before you try any of these optimizations. Removing terminfo files that you don't use, can free up some space. For instance, you could remove all the terminfo files except for linux and xterm. However, this requires knowledge about terminal types. If you do not know what to keep and what to remove, leave the files alone. Secondly, almost all directories in /usr/share can be removed, even if you use the programs that go with them. Take a look at the contents and decide whether you want to take the risk of removing files that look unimportant. Again, if you're not sure if you need the files or not, leave them be. Next up is the hard part. Take a look at each binary installed in your $PATH. If you don't know what a binary does, then read the man page (if you still have it installed ;-)), and decide if you need it or not. If you know what it does, and you know that you don't need it, then remove it. There will be some binaries that don't have man pages, don't offer any help, and who's purpose is not obvious. Play it safe and leave it be in that case. It's not so easy removing stuff from /usr/lib, as it is not obvious what is needed. It is safe to remove the debugging and profiling libraries (those ending in _g.a or _p.a). They can be removed if you do not plan to debug or profile code that uses them. That's it. If you've followed the instructions I provided, your system will now be significantly smaller. Congratulations! ACKNOWLEDGMENTS: Thanks to James Smaby, the author of the lowspace and stripped-down hints. CHANGELOG: [2005-07-31] * Maintainership taken over. * Merged the lowspace and stripped-down hints into one * Various cleanups and updates * Converted to new hint format. * Published the hint on my website.