OLD/lfs-2.3.2-experience.txt

   1 TITLE:          LFS 2.3.2 experience
   2 LFS VERSION:    2.3.2
   3 AUTHOR:         John Phillips <lfs@linux.demon.co.uk>
   4
   5 SYNOPSIS:
   6         Some problems encountered while building an LFS system. All these problems have been addressed in post-2.3.2 versions.
   7
   8 HINT:
   9 I managed to work through 2.3.2 to the point of booting the LFS system.
  10 For what it's worth here are some notes from the experience.  I haven't
  11 been on the list for more than a couple of days so apologies if I raise
  12 points that have long been solved.
  13
  14 Starting point
  15 ==============
  16 * LFS 2.3.2 built from a Debian 2.1r2 (updated to r5) host.
  17
  18 Problems arising from Debian 2.1 (and solutions)
  19 ================================================
  20 * The static linked bash "make install" gave an error because Debian's
  21 install-info is rather old.  I patched the bash doc/Makefile.in to
  22 comment out the call to install-info.  (I might better have upgraded
  23 but the patch was easier and made no difference).
  24
  25 * If you are using X under Debian 2.1 and do the chroot from an xterm, you
  26 may need to do "export TERM=xterm" to avoid confusion over xterm-debian.
  27 This happens with "make menuconfig" while compiling the kernel.
  28
  29 Other problems (and solutions)
  30 ==============================
  31 * I had to compile glibc with the latest kernel headers.  It would not
  32 compile with Debian's 2.0.38 headers since it needs "#define SO_PEERCRED
  33 17" which is in 2.2.14 but not 2.0.38.
  34
  35 To do this, I had to install the new kernel and make the links in
  36 $LFS/usr/include during the static build phase.  I then had to do:
  37
  38     make include/linux/version.h
  39
  40 since glibc needs version.h, which this command makes.
  41
  42 Then to make glibc I added "--with-headers=$LFS/usr/include".
  43
  44 Finally, in the chrooted environment I had to configure the kernel at the
  45 beginning (using defaults for now) because some later compiles need the
  46 "autoconf.h" this generates.  To configure the kernel I did this:
  47
  48     yes "" | make config
  49     make dep
  50
  51 * For some reason I could not properly compile m4 in the chrooted
  52 environment following LFS-2.3.2 as it currently stands.  It would compile
  53 and link, but would not run (because the new glibc claimed it did not
  54 implement "sigstack").  All subsequent compiles needing m4 therefore
  55 failed (including the immediately following autoconf and automake).
  56
  57 The solution (unexplained) was to make a static linked m4 at the end of
  58 the static build phase and then move the m4 re-compile in the chrooted
  59 section to somewhere after autoconf and automake (which need m4, and
  60 which m4 needs under some circumstances).  I actually put m4 after lilo
  61 and before make.
  62
  63 * Permissions issues - (I assume umask 022 has been used for the install):
  64 I had to chmod 1777 for $LFS/tmp and $LFS/var/tmp.  Also for security
  65 there may need to be other changes such as 700 for $LFS/root, and 555
  66 for $LFS/proc (probably others I haven't found yet).
  67
  68 * In the chrooted environment when a utility program is compiled and
  69 then moved, there is a risk that bash will "lose" it by remembering
  70 where it was.  The cure is "hash -r".
  71
  72 * In the binutils install in the chrooted environment there are complaints
  73 about "file" which do not occur in the static build of binutils:
  74
  75    *** Warning: the command libtool uses to detect shared libraries,
  76    *** /usr/bin/file, produces output that libtool cannot recognize.
  77    *** The result is that libtool may fail to recognize shared libraries
  78    *** as such.  This will affect the creation of libtool libraries that
  79    *** depend on shared libraries, but programs linked with such libtool
  80    *** libraries will work regardless of this problem.  Nevertheless, you
  81    *** may want to report the problem to your system manager and/or to
  82    *** bug-libtool@gnu.org
  83
  84 I have not checked if these are significant.
  85
  86 * There are quite a few other warnings in the log files but I think these
  87 are not significant.  Notable (because I don't understand them) are:
  88
  89 binutils static:
  90    libtool: install: warning: remember to run `libtool --finish /usr/lib'
  91
  92 binutils under chroot:
  93    ./libtool: ldconfig: command not found
  94
  95 Neither seems to be a problem.
  96
  97 * For setting up lilo to boot from LFS: The text was not clear to me.
  98 I had to to copy the new kernel to the active (bootable) partition
  99 (which was on the host system in my case), install the edited lilo.conf
 100 there and run lilo there (not in the chroot environment).
 101
 102 * There were "char 45" errors in the net-tools install - I haven't
 103 checked then out.
 104
 105 Minor typos in 2.3.2
 106 ====================
 107 * gcc install on host system - "--enable shared" -> "--enable-shared"
 108
 109 * gzip static linked patch - the directory is wrong, the patch name
 110 is wrong and the patch should not be gzipped.
 111
 112 * sed static linked patch - the patch should not be gzipped.
 113
 114 * findutils chrooted patch - the directory is wrong and the patch should
 115 not be gzipped.
 116
 117 * diffutils chrooted install (title) - "diffuitls"-> "diffutils"
 118
 119 * file chrooted install - directory is file-3.26.orig/ (should there
 120 be a patch for the original?)
 121
 122 * linux86 chrooted install - directories should be .../as or .../ld
 123
 124 * psmisc chrooted install - directory is just psmisc/ (no version number).
 125
 126 * /etc/init.d/syslogd script - "load daemon" -> "log daemon"
 127
 128 * I decided to use the "production" netkit-base-0.16 rather than the
 129 development version (0.17).
 130
 131 * add netkit-base-0.16 and net-tools-1.54 to the mandatory list in ch3.
 132
 133 * /etc/init.d/ethnet file - use ${NAME}, not $(NAME) and there are two
 134 cases where "echo" should be "echo -n".  Change "NETMAKSK" to "NETMASK"
 135 Note also there are potential problems over setting the default route
 136 if you later set up PPP.
 137