binary only lfs system

Geoff Thorpe geoff at
Wed Nov 27 17:43:54 PST 2002

Tommy Moore wrote:

> Morning from Florida.
> I'm interested in building an LFS system for a machine with a small hard
> drive to use as a firewall and small web server. Basically what I'd like
> to do is on another machine is compile LFS and then copy the system back
> over to the slower machine.
> I'd like to save lots of space on this other system so I'd like to strip
> out all the development packages. So what I'd like to do is have a system
> with only the binaries for the programs I'll need compiled with shared
> libraries like  they would be on a normal system. How would I go about
> doing this with out including things like gcc and the other compilers?

I'm working on some stuff to do variants of this which I'll probably contrib 
at some point, but if you want to do it by hand ...

Put the hard-drive in some machine, partition and format it from the 
existing linux setup and create two reasonably large loopback ext2 
filesystems on your *HOST* hard-drive (not your soon-to-be "embedded" 
system). Eg.

dd if=/dev/zero of=bootstrap.img bs=1M count=700
dd if=/dev/zero of=sourcefs.img bs=1M count=700

The idea is that within the "chroot" environment, you will have "/" set to 
the target hard-drive partition (the embedded system's eventual root) and 
the first image will be mounted into "/static" (or "/bootstrap" which I 
use, but the LFS book says "/static"), and the second mounted into 

So, mount the 3 locations;
First, the target root partition (assuming it's the first partition of the 
second IDE drive);
       mkdir /mnt/lfs-build &&
       mount -t ext2 /dev/hdb1 /mnt/lfs-build || echo "failed"
and the two loopback systems;
       mkdir /mnt/lfs-build/static &&
       mkdir /mnt/lfs-build/source &&
       mount -t ext2 -o loop bootstrap.img /mnt/lfs-build/static &&
       mount -t ext2 -o loop sourcefs.img /mnt/lfs-build/source ||
       echo "failed"

Then go about building the bootstrap packages with all those 
"--prefix=/mnt/lfs-build/static" (or $LFS/static if you use the book's 
syntax) options and what-not. Next copy all the lfs-packages-4.0/*.bz2 
files to /mnt/lfs-build/souce - this makes them available when you chroot 
without them taking up space on the destination partition. Now if you 
follow the book's instructions on how to chroot into /mnt/lfs-build to 
build the rest, you should be OK.

Note, if you're prepared to reattach this hard-drive to your host and 
remount the filesystems as above any time you need to upgrade and/or build 
something new, you can get rid of a *lot* of stuff from the target system. 
But first the easy/big savings;

Tweaks: you can probably skip quite a few of the packages;
   - man-pages
   - gcc (you'll always build stuff from the host)
   - vim
   - groff
   - perl
   - linuxthreads (man pages)
   - m4
   - texinfo
   - autoconf
   - automake
   - libtool
   - ed
   - man

that'll save you quite a bit of space, you can also modify the installation 
of some other packages to not install their man/info pages - or you can 
install them and then delete them later with something like;
   find / -type d -xdev -regex ".*\/man\/man." | \
       xargs rm -rf
but I'd run some tests with that sort of thing first :-) A lot of packages 
(eg bash) have a lot of documentation you could throw away and some of them 
have "./configure" arguments for doing it too (eg. experiment with 
--infodir=/tmp perhaps, though I've not tried it).

What else ... oh yes, this is a quite neat way to strip things on x86 
systems that I cooked up that I think does a better (and probably safer) 
job than that recommended in the book - though it's more conservative;

    # Strip executables
    find / -type f -xdev -exec file {} \; | \
        grep "ELF 32-bit LSB executable" | \
        sed -e "s/:.*$//" | \
        xargs strip --strip-all

    # Strip shared libraries
    find / -type f -xdev -exec file {} \; | \
        grep "ELF 32-bit LSB shared object" | \
        sed -e "s/:.*$//" | \
        xargs strip --strip-unneeded

With the above point about always building on your normal host system, you 
could also scan for (and dump) any static libraries on the target system. 
Just change the string used in the "grep" command to "current ar archive" 
and make *SURE* you don't search inside /lib/modules if you use kernel 
modules for anything.

That lets you build much smaller systems with much less in them - that 
should be fine as long as you're happy to install it and not really have 
anything once it's running. If you think to copy the apache and/or iptables 
sources to the "/source"-mounted filesystem before going into chroot, you 
could also go ahead and extract/build/install those too from the chroot 
environment. Once that's all done, you've installed and configured lilo 
properly, [etc] you should be able to put the hard-drive back in your 
little machine and away you go.

Oh I nearly forgot - when building the system from the chroot environment, 
you'll absolutely *HAVE* to make sure that gcc won't generate binaries that 
can't run on your target machine (eg. if you build on an athlon but your 
target machine will be a 486, you could have problems). I haven't tried 
this out myself yet (I'm working on UML systems so this isn't an issue for 
me) but I will soon as I also have a little machine I want to put LFS on. 
However at a guess I'd recommend setting the CC environment variable to be 
"gcc -<foo>" where "<foo>" is the gcc switch to control the output 
(-march=pentium or something like that usually). At worst, you could 
perhaps just move the 'gcc' binary and replace it with a shell script that 
redirects the command-line arguments to the real gcc binary after doing any 
checks and substitutions first. Or if you're a masochist you could change 
the bootstrap installation of gcc with a cross-compiler targetted to your 
destination system ... either way you're on your own ... :-)

Good luck.


Geoff Thorpe
geoff at

Unsubscribe: send email to listar at
and put 'unsubscribe lfs-support' in the subject header of the message

More information about the lfs-support mailing list