r974 - in trunk: OLD PREVIOUS_FORMAT

tushar at linuxfromscratch.org tushar at linuxfromscratch.org
Tue Aug 2 14:22:01 PDT 2005

Author: tushar
Date: 2005-08-02 15:22:00 -0600 (Tue, 02 Aug 2005)
New Revision: 974

Moved Hint stripped-down to OLD; merged into small-lfs

Copied: trunk/OLD/stripped-down.txt (from rev 973, trunk/PREVIOUS_FORMAT/stripped-down.txt)

Deleted: trunk/PREVIOUS_FORMAT/stripped-down.txt
--- trunk/PREVIOUS_FORMAT/stripped-down.txt	2005-08-02 02:38:54 UTC (rev 973)
+++ trunk/PREVIOUS_FORMAT/stripped-down.txt	2005-08-02 21:22:00 UTC (rev 974)
@@ -1,146 +0,0 @@
-TITLE:		Stripping down an LFS
-AUTHOR:		James Smaby <jsmaby at virgo.umeche.maine.edu>
-        A freshly built LFS is smaller than most distros, but still contains
-        much cruft that can be removed.  Knowing what to remove takes knowing
-        your system, but here are some pointers.
-    This hint can be followed right after building LFS, or perhaps best, after
-all additional software is installed as well.  Stripping a system mostly takes
-going through all the directories and removing stuff you don't need/use.
-    If you are looking for a small system, you should consider compiling stuff
-with -Os, which tells the compiler to optimize for size, usually a good thing.
-It is normally okay to compile with -fomit-frame-pointer, but do not use it on
-glibc or anything you plan on debugging.  If you don't use NLS, you can config
-packages with --disable-nls to conserve some room.  Adding -s to your LDFLAGS,
-or using "gcc -s" as your CC will save some work later, because most libraries
-and binaries will be already stripped before installing them.  Stripping glibc
-while the system is running, for instance, can be problematic.
-    Before getting started, maybe ask yourself if it might be best to build up
-the system in an additive manner, copying over the files you need (like for a
-floppy-based router) instead of removing stuff you don't need.  Perhaps using
-busybox will meet your needs better than LFS in this case.
-    The first thing I like to do is remove things from /usr/share, like docs
-and locales.  If you use info, you can compress the info pages.  Otherwise,
-remove them.  Then do the same with /usr/share/man and /usr/share/doc.  You
-could do what I do, and keep compressed man pages, and remove the docs dir
-and the info pages.  Note that in order to compress the man pages, you may
-have to fix some links between them.  Look for hard links by:
-  # ls -l /usr/share/man*/* | grep -v "1 root"
-and symbolic links by:
-  # find /usr/share/man -type l
-In the case of hard links, decide which one you want for the master copy
-and remove the others.  You can then recreate the others by:
-  # echo ".so gzip.1" > /usr/share/man/man1/zcat.1
-for instance.  Make sure you remove the link first otherwise the master
-copy will be clobbered.
-    You can remove any locales, timezones, and keymaps that you don't
-use.  If you don't use NLS, you can remove all the locale info (there
-is data in /usr/share/locale and /usr/lib/locale), although you might
-get warnings like
-  Gdk-WARNING **: locale not supported by Xlib, locale set to C
-from gtk-using apps, which can be ignored (or hacked from of the glib
-source code).
-    If you copy your timezone to /etc/localtime instead of making the
-normal symbolic link, all of /usr/share/zoneinfo can be removed.  You
-can remove /usr/share/kbd, and either create a keymap file somewhere:
-  # dumpkeys > /etc/dvorak.map
-or compile your keymap into the kernel:
-  # dumpkeys | loadkeys -m - >/usr/src/linux/drivers/char/defkeymap.c
-The keymap file will have to be loaded upon startup, while if it's put
-in the kernel, the system will start with that keymap loaded.  One can
-not simply copy the keymap file from /usr/share/kbd because those maps
-include files, and tracking down all the dependencies is a pain.  Using
-dumpkeys will insure that all the needed info is in one file.
-    You can remove terminfo files that you don't use.  For instance, you
-could remove all the terminfo files except for linux and xterm, but this
-takes knowing what terminal types you use; If you do not know, leave them
-alone for now, and you'll see what files aren't used later.
-    If you don't use the auto tools in any of your projects, and you don't
-download source from cvs which relies on autoconf to build (like if there's
-a autogen.sh but no configure script), it's safe to remove /usr/share/auto*
-and /usr/share/aclocal*.
-    Basically, most of the dirs in /usr/share can be removed even if you use
-the programs that go with them.  Take a look inside the dirs, and if none of
-the files look `important', remove it.  If you want to play it safe, move the
-files to a temporary place, and see if anything misses their absence.  My own
-system, with various extra programs installed, has a /usr/share that is like:
-  aspell dict        gnuplot.gih irssi   man  psutils  texmf
-  bison  ghostscript groff       libtool misc terminfo vim
-Again, if you're not sure if you need the files or not, leave them be, and you
-will see which files get used later.
-    Next up is the hard part; look at each binary installed in the PATH: /bin,
-/sbin, /usr/bin, and /usr/sbin.  If you don't know what it does, then read the
-man page, and decide if you need it or not.  If you know what it does, and you
-know that you don't need it (like bzdiff, dir, bashbug, etc.), then remove it.
-This is the point where you get to really learn your system.  There'll 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.  You'll get to see if
-it is not used later.
-    Chances are, your /usr/sbin will be pretty small after stripping it down.
-I like to just move whatever is left in there to /sbin, and have one less dir
-in my PATH.
-    It's not so easy removing stuff from /usr/lib, as it is not obvious what
-is needed.  Indeed, ldd doesn't even show all of the runtime dependencies as
-a binary could load shared libraries after running.  It is safest to remove
-only the debugging and profiling libraries, and leave it at that.  A couple
-packages might install these (glibc and and ncurses), and they end in _g.a
-or _p.a.  They can be removed if you do not plan on debugging or profiling
-code that uses them.
-    The .la files installed by libtool are unneeded by anything that I've
-found (except some for parts of kde), and can be removed (well, I always
-remove them and haven't run into trouble yet).  They're pretty small but
-they add clutter, and clutter is a bad thing.
-    The static libraries will not have been stripped by `-s' since they
-are not linked so strip out the debugging symbols now:
-  # strip -g /usr/lib/*.a
-Now is as good a time as any to look for any other binaries that need
-stripping.  Run the following command to see which programs/libraries
-still have debugging symbols in them:
-  # find / -exec file {} \; | grep "not stripped"
-This will print out the names of some binaries that didn't honor your
-CC or LDFLAGS, and a few other files, maybe in subdirs of /usr/lib or
-hiding in odd places.  If it ends in .o or .a, use strip -g on it, so
-that you don't clobber all the symbols.  Any other binary is probably
-linked, so can be run with just plain strip.  Do not strip any binary
-or library that's currently in use, as it's possible that the program
-using it will crash.  If the strip program, bash, or glibc need to be
-stripped, I recommend doing so from the host.
-    There's still a lot that can be removed, like subdirs of /usr/lib,
-files in /etc, and binaries you are not sure are needed or not.  Maybe
-the easiest way to find out what to keep is to do the following:
-  # touch /var/tmp/timestamp
-Now use the system like normal.  Reboot a couple times.  Build a kernel.
-Maybe build another LFS. Just use the system.  After a week or so of use
-you will have accessed any files that will ever need to be accessed.  Run
-the following command to see which files have not been accessed since you
-touched the timestamp.
-  # find / -not -anewer /var/tmp/timestamp
-Now go through this listing, and look for anything that looks important, or
-that you know you might someday want (like documentation).  Everything else
-can most likely be removed.  If you want to be safe, move all the files to a
-temporary location out of the way.  Maybe put them on a cdrom backup.
-    Note that for this trick to work, nothing should be mounted read-only or
-noatime during the usage time, otherwise the atime's of the files will not be
-updated, and everything will appear to be unused.
-    After you have your system stripped down, look through every directory for
-anything you don't want.  This may include some files that you accessed during
-the usage time, but didn't mean to (like looking inside configuration files in
-/etc to see what's in them).
-    Another good thing to do in the final pass-through is to use du -sh on the
-different directories to see how much space they are taking up.  If you find a
-particularly bloated one, concentrate efforts on slimming it down, like if you
-see that /usr/include is taking up more room than you want it to, you could do
-a very evil thing and strip out all the comments from the header files.
-Good luck, have fun, and I hope you made a backup first ;-)

More information about the hints mailing list