LFS Frequently Asked Questions

The FAQ is divided in three documents. The General FAQ has links to all questions and answers. The LFS FAQ is a selection of LFS-specific FAQ's and the BLFS FAQ is a selection of BLFS-specific FAQ's.

Frequently Requested Enhancements

When reading and building LFS

General compilation errors

Package-specific errors

Configuration and booting issues

Frequently Requested Enhancements

Why not use LILO instead of GRUB?

Since LFS-5.0, released 5 November 2003, LFS uses Grub instead of Lilo. Grub was chosen because it doesn't require reinstallation after a kernel upgrade and has a very nice rescue console.

If your current setup uses LILO or you'd like to use it anyway, you can, but beware you will also need to install BIN86 and, for the latest LILO versions, NASM. However, don't preach about it on the LFS mailinglists, since we've had many flamewars about it in the past.

Why not include the FAQ in the book?

Marc Heerdink may have said it best in a post to lfs-dev:

The problem is that the FAQ is a dynamic document. The FAQ for a book release is released only after the book version itself, because the FAQ is updated to reflect the Qs asked about the current version of the book. A link is better, since you'll always have the most up-to-date answers handy.

Why is vim in the book?

This is fairly well discussed in the thread starting at http://linuxfromscratch.org/pipermail/lfs-dev/2002-February/023030.html.

Why is HJL's Binutils not in the book?

The binutils release that you typically find on ftp.gnu.org is commonly known as the "FSF" binutils. Noted hacker H.J. Lu also makes releases out of the main CVS repository and these are commonly known as the "HJL" binutils and can usually be found on ftp.kernel.org. Debate often arises over which version to use due to the fact that most mainstream distros tend to use the HJL releases even though they are typically marked as "beta".

Here is our interpretation of the differences between the two:


  • For Linux OS only
  • Marked as "beta"
  • Closely follows the CVS HEAD
  • Usually contains the latest subtle bug fixes
  • Usually has latest bug fixes for non-x86 arch's
  • Usually a new release every time a significant bug that affects Linux gets fixed
  • Theoretically less stable due to newness of code


  • Supports more OS's (not only Linux)
  • Latest code from the stable branch of CVS
  • Sometimes not up-to-date WRT to the latest bleeding edge kernel, gcc and glibc subtleties
  • Often includes features backported from the CVS HEAD after a period of testing
  • Theoretically more stable

You'll notice in the above points words like "usually" and "sometimes". This demonstrates how the situation can be different depending on which particular point in time you happen to be referring to. For example, from time to time there will be a new bleeding edge feature in gcc or glibc that requires support from binutils. During these times you will often hear the developers say "you must be using the latest HJL binutils version x.y.z.a.b".

The only way to correctly choose the most appropriate release to use is to:-

  • Stay abreast of the issues on the project mailing lists of the core toolchain packages
  • Have a large dose of technical prowess and/or programming talent to understand all the issues
  • Test like crazy by running the test suites
  • Test like crazy by building full systems

The facts of the matter are that the core toolchain packages are all very tightly bound and must be tested to ensure they work together. You basically have to build a full working distro and test every aspect of it to be fully satisfied.

If you follow the project mailing lists of the core toolchain packages for long enough, you'll soon realise that the developers do not care much whether a particular release of "Package A" works with a particular release of "Package B". In other words, release coordination between the projects is not a priority. In reality, this means that Alan Cox is right when he says that you cannot just go to ftp.gnu.org and grab the latest of everything and always expect it to just work.

Why isn't some package manager in the book?

Package management - beyond that provided by tarballs and makefiles - is beyond the scope of the book. If nothing else does, the number of different "solutions" should hint at some of the reasons.

Here are a few of the options:

If you have an addition to the list, please do email its id, URL, and other information, to the FAQ maintainer or an appropriate LFS mailing list so it can be added here.

How do I make my machine poweroff when shut down?

Power Management is a kernel function, you need to enable it in the kernel. In the 2.4 kernel, you have to enable the options for Power Management Support under General Setup. For older machines, you'll probably want the APM options, newer machines often require ACPI. Make sure that either APM or ACPI be enabled in the kernel, but definitely not both at the same time - this has been known to cause problems such as neither actually taking effect. Also try disabling SMP if you only have one processor; it's also known to prevent a proper poweroff. Make sure you read the help with each option.

After rebooting into the new kernel you should be able to poweroff your machine with the command shutdown -h now or poweroff (also read man shutdown and man halt). If you compiled APM or ACPI as modules, make sure they are loaded before you try to power off. Some machines require that APM or ACPI is compiled into the kernel because it needs to be initialised at boottime.

Back to the top.

When reading and building LFS

What distribution should I use to start from?

Most relatively recent distributions should be fine. Do not use Fedora Core 4 as its version of GCC does not work with the current stable version of LFS. Make sure you have installed and/or updated the development packages. (Look for ones starting in "gcc", "glibc", or "libstdc++" or ending in "-dev".). If you want to use LFS as your main system and you wish to install it without first installing a distribution, try the LFS LiveCD or Knoppix.

How do I compile a kernel or set up modules?

In addition to the kernel documentation at /usr/src/linux/Documentation or wherever you unpacked your kernel source and the help in kernel config tool (make menuconfig), see the Module-HOWTO at http://www.tldp.org/HOWTO/Module-HOWTO/.

Are compiler warnings from GCC bad?

Short answer: no.

Long answer: probably, but only to someone working on the package you're trying to compile. Mostly, everything will be fine unless make quits with an error.

Here's an example:

sk ~/tmp $ cat > Makefile
gcc main.c
sk ~/tmp $ cat > main.c
void main() { exit(0); }
sk ~/tmp $ make
gcc main.c
main.c: In function `main':
main.c:1: warning: return type of `main' is not `int'
sk ~/tmp $ ######## that worked ########
sk ~/tmp $
sk ~/tmp $ cat > main.c
int main() { exxit(0) }
sk ~/tmp $ make
gcc main.c
main.c: In function `main':
main.c:1: parse error before `}'
make: *** [main] Error 1
sk ~/tmp $ ######## that failed ########
sk ~/tmp $

How do I make that really small install the book mentions?

Gerard describes the process of making a 5MB LFS install in an email to lfs-support, and there are links to many resources in a post by Cor Lem and a reply to it.

Is there information about building LFS on other processors?

For information about building LFS for a wide array of systems, take a look at the Cross-LFS branch of LFS.

The Alpha systems, Kelledin maintains a list of fixes for building on the Alpha platform at http://skarpsey.dyndns.org/alpha-lfs/alpha.html.

How do I cross compile LFS?

It's often useful to compile LFS for one machine on another machine. Say using that fast 1Ghz Athlon to build an install for an old 486. While this is technically not cross compiling, binaries compiled for the Athlon cannot be run on the 486 because binaries compiled for the newer processor use features the older processor doesn't have.

The LFS book specifically for cross compiling is the Cross-LFS book. Another source of information would be the cross-compiling hint.

What's a DOS format text file?

It has to do with the characters used to end lines.

There are two that may be used:

  • Line Feed: (LF) Octal:012 Decimal:10 Hex:0A C Style Escape:'\n' Moves down one line.
  • Carriage Return: (CR) Octal:015 Decimal:13 Hex:0D C Style Excape:'\r' Move to the left margin.

Unix, DOS, and MacOS each use a different combination to end lines in text files:

  • Unix: LF only. This is why when a Unix format text file is sent to a printer raw, it prints out
  • DOS: CRLF both. Which is why if you do "cat -v" on a DOS file you'll see a "^M" (control m is carriage return) at the end of each line. And that is why scripts don't work when written with Microsoft Notepad. The kernel looks for "/bin/sh^M" which doesn't exist. There's a "/bin/sh", but nothing with a "^M" appended.
  • MacOs: CR only. Printers probably print every line atop the first, and Unix tools think the whole file is one line with "^M" all through it.

To change DOS to Unix, use

cp <fileid> <fileid>.dos &&
cat <fileid>.dos | tr -d '\r' > <fileid>

Or in vim, you can convert a file with :set ff={unix, dos, mac}. Other conversions will probably require sed or a different use of tr and are left as an exercise for the reader.

Back to the top.

General compilation errors

I used a patch from GNU to upgrade. Is that OK?

Patches from GNU don't usually work. You can either download the full archive and try again or try the solution given by Gerard Beekmans:

The problem is that executable marked scripts are patched too and they then lose the executable bit, so you can't execute those scripts anymore until you run a "chmod +x" on them (or something similar, like chmod 755) before installing Glibc. Try chmod +x glibc-2.2.5/scripts/* (not 100% sure about the directory paths but it should be obvious where to do it when running an 'ls' on the glibc-2.2.5 directory).

When using optimization flags (setting CFLAGS)

If you're getting errors and you're setting CFLAGS or otherwise passing optimization flags to the compiler that may be the problem.

If you ask on the list and they can't figure it out immediately, they'll likely suggest trying it without optimization. So if you just retry it without before asking, you'll be one step ahead of them :)

Of particular note is that optimizing binutils, gcc, or glibc may cause any other package to fail to compile or run or to otherwise misbehave in strange and mysterious ways. Also, optimization that works for someone else may not work for you. Flags that used to work may mysteriously stop working. Even some small innocent hardware change can make the difference.

(If you don't know what optimization flags are, don't worry, you really don't need to.)

Why does configure hang at "checking for signed size_t type..."?

You over optimized gcc.

I didn't delete the source tree after my last attempt. Do I need to?

Yes. In general make clean or make dist-clean can't be relied upon for clean sources. Especially when you have manually hacked the sources or applied patches to it you should first try again with a fresh unpacked package. The only exception to this rule is the linux kernel, which requires its sources to be present when third-party modules, such as the NVidia drivers, are needed.

I'm getting `/dev/null: Permission denied'

Does /dev/null look like this:

$ ls -l /dev/null
crw-rw-rw- 1 root root 1, 3 Aug 3 2000 /dev/null

If not, it should. See the chmod(1), chown(1), and mknod(1) man pages and /usr/src/linux/Documentation/devices.txt if you need help fixing it.

If it does look right, the problem is probably your mount options. See the answer to "./configure: bad interpreter: Permission denied", above.

signal 11 (internal error: Segmentation fault)

The long answer is at http://www.bitwizard.nl/sig11/.

The short answer is that if restarting make gets a little further every time, you have a hardware problem. (If make, or whatever you're running, fails at the same place every time, then it is not hardware.)

Assuming you're not overclocking, the most likely hardware problem is bad memory which you can check with Memtest86 from http://www.memtest86.com/. If that isn't it, see the long answer.

No such file or directory

Examples of this error are:

/usr/bin/env: /tools/bin/bash: No such file or directory
gcc: No such file or directory

With the new Ch 5 build procedure, the most common cause of this problem is forgetting to apply the specs patch.

What happens is that the path to the dynamic linker embedded inside the executable is still pointing at /lib/ld-linux.so.2 and when one goes to run the binary inside the chroot where /lib/ld-linux.so.2 does not exist yet, the very unhelpful No such file or directory error message is shown.

You can test this with readelf -l {binary} | grep interpreter. It's output should be: Requesting program interpreter: /tools/lib/ld-linux.so.2.

bash: ./configure: No such file or directory

You forgot to cd into the extracted directory of the package after you've extracted it.

./configure: bad interpreter: Permission denied

You're most likely getting this while building binutils in Chapter 5 of the LFS Book. The problem is most likely your mount options. You probably have a line in /etc/fstab like:

/dev/hda10 /mnt/lfs ext2 user 1 2

'user' is the mount flag, and it's the problem. To quote from the mount man page:

user: Allow an ordinary user to mount the file system. This option implies the options noexec, nosuid, and nodev (unless overridden by subsequent options, as in the option line user,exec,dev,suid).

So change the line in /etc/fstab like this:

/dev/hda10 /mnt/lfs ext2 defaults 1 2
configure can't guess my host type.

Typical symptoms look like this:

sk ~/tmp-0.0 $ ./configure
creating cache ./config.cache
checking host system type...
configure: error: can not guess host type; you must specify one
sk ~/tmp-0.0 $

The problem is usually that the script can't run the compiler. Usually it's just a missing /usr/bin/cc symlink. You can fix it like this:

cd /usr/bin && ln -s gcc cc

If that doesn't do it, check the file config.log created by configure. Errors go there and may indicate the problem.

checking whether we are using GNU C... no

If you're getting an error from configure like:

checking whether we are using GNU C... no
configure: error: GNU libc must be compiled using GNU CC

It may be because egrep isn't working. Since egrep is a shell-script which calls grep, this actually means there's a problem with grep.

To test if grep is working before reinstalling the grep package in Chapter 6, run the following command from outside chroot:

file $LFS/bin/grep

If it doesn't say statically linked you have a problem and need to reinstall the grep package according to the instruction in chapter 5.

To test if egrep is working after reinstalling the grep package in Chapter 6, run the following command from inside chroot:

egrep root /etc/passwd

If it doesn't print root's line from /etc/passwd, again, you have a problem. (This test also works if you encounter the problem after rebooting into the new LFS system.)

The system has no more ptys. Ask your system administrator to create more.

If you run

expect -c "spawn ls"

and get the following error:

The system has no more ptys.
Ask your system administrator to create more.

then your linux distribution is either not setup to use Unix98 PTYs or to use the /dev/pts file system.

The solution may require recompiling your kernel. First, go to your kernel's source directory and look at the .config file. If you do not have a .config file, and you are running the pre-compiled kernel that was installed with rpm, aptget, or whatever your distribution uses, then you need to seek support from your distribution's support FAQ's, mailing lists or IRC channels.

If you do have a .config file, look inside it for the following 2 options:


If either of these has 'n' instead of 'y', then change it and recompile the kernel.

If they both have 'y', then you probably will not have to recompile the kernel.

Next, we need to ensure that the system is actually using both Unix98 PTYs and the /dev/pts file system.

First, look for a device called /dev/ptmx. If it doesn't exist, create it with:

mknod /dev/ptmx c 5 2

Then, whether it existed or you just created it, run:

chmod 666 /dev/ptmx

Next, ensure that there is a directory called /dev/pts. The permissions should be 755. Create it and/or chmod it if needed.

The final setup is to add the following line to /etc/fstab:

devpts    /dev/pts    devpts    gid=5,mode=620    0  0

NOTE: Look for the tty group in /etc/group and note the group id number. Change the gid=5 option to match the group id number of the tty group. The group id of 5 is just an example and may differ on your system.

Now that everything is setup, you have two options.

1. Mount /dev/pts and test it by rerunning the above expect command.

2. Reboot the computer and test it by rerunning the above expect command.

Back to the top.

Package-specific errors

GCC: Error: Unknown pseudo-op: `.hidden'

If compiling GCC in Chapter 5 errors out with

Error: Unknown pseudo-op: `.hidden'

Try the solution given in the lfs-support archives and replies.

Glibc: "... it is normal to compile GNU libc with the `linuxthreads' add-on..."

The exact error looks like this:

*** On GNU/Linux systems it is normal to compile GNU libc with the
*** `linuxthreads' add-on. Without that, the library will be
*** incompatible with normal GNU/Linux systems.
*** If you really mean to not use this add-on, run configure again
*** using the extra parameter `--disable-sanity-checks'.

You did not pass the --enable-add-ons parameter to configure, which enables the NPTL threading add-on. Glibc will not ask for linuxthreads with this parameter.

Glibc fails and mentions BEGIN and END.

If glibc fails to build with an error like this:

'BEGIN { subdirs = ""; inhibit = "" }; \
^# { next }; \
^[^-] { subdirs = subdirs " " $0 }; \
^- { inhibit = inhibit " " substr($0, 2) }; \
END { printf "sysdep-subdirs =%s\n", subdirs; \
printf "sysdep-inhibit-subdirs =%s\n", inhibit; \
print "sysd-dirs-done = t" }' \
/dev/null linuxthreads/sysdeps/pthread/Subdirs
sysdeps/unix/inet/Subdirs sysdeps/unix/Subdirs >
/bin/sh: line 1: BEGIN { subdirs = ""; inhibit = "" };
^# { next };
^[^-] { subdirs = subdirs " " $0 }; ^- { inhibit =
inhibit " " substr($0, 2) }; END

then gawk is failing. The key is the BEGIN and END in the output. The probable reason is that it's not statically linked which you can fix by going back to Chapter 5 and recompiling it.

Glibc compilation errors out due to a missing nss.h header file

This usually indicates that you are compiling LFS onto a Reiser4 partition. Unfortunately, there is currently no known solution, other than to use a different type of filesystem.

NCurses: C++ preprocessor "/lib/cpp" fails sanity check

Ncurses in chapter six ends with:

checking how to run the C++ preprocessor... /lib/cpp
configure: error: C++ preprocessor "/lib/cpp" fails sanity check

The problem is that you have no c++ compiler. In chapter five, gcc is first built without the C++ compiler. Before building ncurses, gcc is rebuilt with the C++ compiler. Most probably, you forgot to extract the g++ tarball, or did not specify "c++" in the --enable-languages configure switch, on the 2nd gcc build. There are more details in the mail archive.

Back to the top.

Configuration and booting issues

Kernel panic: VFS: unable to mount root fs

There are several reasons why the kernel might be unable to mount the root filesystem.

  • Did you specify the correct partition in /boot/grub/menu.lst?
  • Is support for the hard drive enabled in the kernel. For SCSI this means support for the specific SCSI adapter.
  • Is support for the hard drive compiled into the kernel, not just as a module. (Modules are stored on the filesystem. If a driver needed to access the filesystem is stored as a module on that filesystem, well ... you know ... ;)
  • Is support for the filesystem compiled into the kernel. Again, not a module. Support for ext2 is enabled by default, but others like ext3, reiser, jfs, and xfs are not.
init: Id "1" respawning too fast: disabled for 5 minutes

When you see, in your syslogs, this line:

init: Id "1" respawning too fast: disabled for 5 minutes

It means you have an error in the /etc/inittab line beginning with the given id ("1" in this example).

modprobe: Can't locate module char-major-10-135

char-major-10-135 refers to the character device, major 10, minor 135, which is /dev/rtc. It provides access to the BIOS clock, or RTC, the Real Time Clock. See /usr/src/linux/Documentation/rtc.txt for more information.

The error is because something, most likely hwclock, is trying to use /dev/rtc but you haven't configured kernel support for it in your kernel. Either delete /dev/rtc so hwclock won't try to use it or enable RTC support in your kernel. It's located in make menuconfig under "Character devices" -> "Enhanced Real Time Clock Support".

modprobe: Can't locate module /dev/rtc

See the question "modprobe: Can't locate module char-major-10-135".

eth0:unknown interface:No such device [failed]

The full error looks like this:

eth0:unknown interface:No such device [failed]
Setting up default gateway...
SIOCADDRT:No such device [failed]

eth0 is a virtual device with no /dev entry. It refers to the first detected network card in your system. The reason the kernel can't find this device is because you forgot to add support for your network card in the kernel. The kernel detected the card but doesn't have a driver for it. The LFS boot script tries to bring up the network but fails because of this.

Recompile your kernel with the proper driver, either built in or as a module. If you compiled the network driver as a module, then also adjust /etc/modules.conf to alias the network card module as eth0; for example: alias eth0 8139too. If you don't know which network card you have, you can use dmesg, /proc/pci or lspci to find out.

spurious 8259A interrupt: IRQ14

Short summary: It's a hardware problem (usually). Transient Line-noise/crosstalk persuades the PIC that something happened; this can result in a 'dummy' interrupt being raised, which happens to be IRQ7 with intel's 8259 design.The problem could possibly also be caused by (or instead be caused by) a device driver not properly masking its interrupts before servicing, this would be the suspect if the IRQ7's were happening in bursts, or more often than 'several' per day. (Source and additional information)

Since the message itself is harmless, it's enough to adjust the default loglevel outplut of klogd (the -c opion) in the syslogd bootscript. See man klogd for details. You can also try recompiling the kernel and unset CONFIG_LOCAL_APIC.

Why does less (and therefore man) print <AD> instead of hyphens?

Because the LANG and LC_ALL environment variables aren't set. To fix that, set them in both the ~/.bash_profile and ~/.bashrc files for each user or in /etc/profile, which will take care of all users, by adding lines like this:

export LANG=en_US

Those lines can be added to /etc/profile with the following command:

echo -e 'export LANG=en_US\nexport LC_ALL=POSIX' >> /etc/profile

If you don't use US English you'll have to change the "en_US" part and possibly the values of various LC_* variables as well. Running the locale command lists many (all?) of the LC_* variables.