LFS on ancient system
areiner at tph.tuwien.ac.at
Sat Nov 22 14:28:34 PST 2003
I wanted to use LFS as a smooth upgrade path for a rather old Linux
system. In the following I provide a short overview of what I have
tried (mainly for the archive, in case there is anyone else with those
problems) and a few questions on my options.
(I have read the FAQ, and I have perused the search on the home page
whenever I ran into trouble and couldn't figure things out by
myself. I've been using Linux exclusively for a couple of years and
know my way round the system quite well, but I have never been
interested in languages like C, C++, Java.)
* Host system, objective
This is a rather old PC (probably from 1998 or earlier):
AMD K6, 266MHz
8GB ATAPI hard disc, with partitions
approx 300MB: MS-DOS (practically unused)
approx 130MB: Linux swap
rest: Linux / (ext2)
Furthermore, the BIOS is pretty old (not y2k-compliant, the startup /
shutdown scripts always perform a jump by a couple of years). There is
a CD-ROM drive, but the BIOS doesn't offer to boot from CD;
furthermore, I do not have access to a CD-writer. Zip discs are used
for backups; the computer also still has floppy drives. Net access is
dial-up only, and my modem is old and slow. At this point I am not
willing to upgrade the hardware.
The Linux installation I have is quite old, too: it used to be a SuSE
5.3 or so, but the first thing I learned was that I didn't like
yast. I always compiled things by myself (which is why I think that
LFS is a good way for me to go), but I never cared to learn C and
similar languages and can make only the most simple of
changes. Anyway, my Linux is running the following versions:
makeinfo (GNU texinfo 3.12) 1.68
GNU bash, version 2.01.1(1)-release (i586-pc-linux-gnu)
Patch version 2.1
(which implies an upper file size limit of 2GB).
I also have access to another PC of comparable age but with a more
recent Debian/stable (kernel 2.2.something, I think); I'll call that
the 2.2-box henceforth. Unfortunately, it suffers from a RAM problem,
especially in cold and humid weather.
On my machine I have a lot of valuable data that I do *not* want to
loose (I do have backups, though) as well as software I've written and
not all of which is mirrorred elsewhere. Unfortunately, I increasingly
find that I cannot upgrade those tools that I do use and need
(compilers, even TeX) simply because they expect a more modern setup,
This is why I thought that LFS with the hint on installing next to an
existing system might provide a good way of gradually upgrading the
system. MY ABSOLUTE PRIORITY is to retain the old system functioning
until I have made sure that ALL the critical software I need can be
transferred to the new system and behaves as expected; I am ready to
scrap the new LFS system if this turns out not to be feasible, or if a
more modern Kernel turns out too demanding for my hardware. Also, I
do not want to run the risk associated with re-partitioning, even
though it's pretty obvious to me that what I have now is far from
optimal (also, I wouldn't want to bet that the necessary ext2
utilities compile on my system, see below).
Furthermore, I have a lot of work to do, which means that I can allot
time to installing LFS only every now and then, even though I try to
stay up to date with respect to LFS by following the mailing lists.
* Failed attempt with LFS 4.1
This was started quite some time before 5.0 was released, so I went
for LFS 4.1. I did most of Ch. 5 and failed in Ch. 6. I downloaded
all packages as one big tar ball and made sure the versions match
those of the book.
As a general observation, I found it very valuable to use script(1) to
record whatever I did for installing some package, as well as to scan
for compiler errors from another terminal. In particular, this makes
it much easier to figure out how far you got with the installation if
you have to interrupt the process, as well as to figure out where
something went wrong in the first place. (Maybe this suggestion should
go to the book?)
** deviations from the book
As mentioned before, I wanted to use the next-to-existing-system hint.
Trivial: On my system patch does not know the -i option; instead, I
had to use patch -Np1 < ... .
I also found it practical to also create a group lfs with me and the
lfs user as members so that I can use my running emacs to edit any
config files etc. owned by lfs. Consequently, chown lfs:lfs $LFS; and
umask 002 instead of 022.
For completeness' sake: in ch. 6 I did not see any reason for an audio
** problems with individual packages in Chapter 5
Some packages did not compile out of the box; in most cases I could
work around the problems:
configure gave me:
checking for working mktime... no
make resulted in a lot of errors related to mktime. I recompiled on
the 2.2-box, which worked (tested a couple of simple scripts).
This configures just fine, but compiling stops due to a missing
sys/ucontext.h; sure enough, there is no file of that name on my
machine. I tried to compile on the 2.2-box, but that did not work out
due to the bad RAM.
I then tried to make a static build on an account on a more "current"
Linux installation (Kernel 2.4? 2.6?), but I cannot use that on my
$ ./static/bin/gcc --version
FATAL: kernel too old
There is no problem installing 2.95.3, however, and I tried to proceed
That didn't work because of my way too old version of makeinfo. I
don't really think it is a good idea for inability to build the
documentation to cause the installation to fail altogether. Anyway, I
compiled on the 2.2-box, works fine.
*** Make-3.80, Sed-4.0.5, Texinfo-4.3
In all these cases configure segfaulted. Make and sed I compiled on
the 2.2-box. For texinfo I did not bother, and replacing #!/bin/sh by
#!/lfs/static/bin/bash in the configure script worked like a charm.
Make seemed to hang; no problem on the 2.2-box.
** chapter 6
To cut a long story short: The only gcc I could install in Ch. 5 was
2.95.3, and glibc-2.3.1 complains that gcc is too old, and that was
the end of it :(
I have had only a cursory look at the LFS 5.0 book, but I did not get
the impression that my problem - gcc-3 needs some header file I don't
have, and glibc-2 needs gcc-3 - is solved there.
So now I seem to have about three options:
- Forget about a smooth upgrade in general, and LFS in
particular. (Which is not necessarily a tragedy, though I'd rather
- Somehow manage to get a statically compiled gcc 3.2.something and
continue from there (in which case there is the question of LFS 4.1
Ideally someone would point me to a statically linked gcc binary
that works with the 2.0.35 kernel and has the correct paths
hardwired (--prefix /static), but my expectations are not very high
in this respect.
Or would it be sufficient to find a static binary that runs on
2.0.35 and to somehow manipulate the elf (?) files so as to change
the paths? If so, I'd need detailed instructions (as well as a
pointer to a binary, if possible), as I don't know anything about
Or does anyone know how I might trick gcc into compiling on my
system? For some other compiler (nhc) it was sufficient to edit a
couple of files and use the CYGWIN settings. Unfortunately, I do not
know enough to figure that out by myself.
- Get rid of DOS and install a minimal Linux on that 300MB partition,
compile everything from there, possibly adapting the "next to
existing installation" hint as necessary. In this case, I would
welcome any advice on the following questions (as well as anything
else that might be relevant):
- LFS version: If I have to start all new, LFS 5.0 seems to be the
more natural candidate; OTOH, there seem to be quite a few people
experiencing problems with this release. As you may have guessed,
I am not really interested in running the latest and greatest, so
4.1 would probably be fine for me, too.
- Host distro: This must be small enough to fit into 300MB, and
contain sufficient software for compiling the toolchain (besides
gcc, binutils, and system headers, what else would I need?). Also,
I have to install it from floppies (no CD writer, CD not bootable)
and I'd like to keep the pile small. Any suitable distribution?
What about a minimal debian plus gcc?
$LFS would again be on / in my current Linux partition, which
itself should be mounted on the 300MB partition, so that the host
distro can have all the 300MB for itself.
- Next-to hint: I haven't thought a lot about this, but would I need
to use the next-to-existing-system hint in this setting?
So what do you think about what I should do next in this respect? I am
under the impression that the last of the three options is the most
promising one. Any input would be appreciated.
P.S.: Usually I connect to the internet only once a day, which means
that I may be quite slow in replying.
 I don't really expect this, but what I keep hearing about Windows
seems to suggest that every new version incurs a huge performance
penalty. (3.1 was the last Windows I used.)
 Maybe a couple of hours per week (including what other people
consider to be "weekends").
More information about the lfs-support