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 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 this post.

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:

  • No package management is really necessary. Unless it is desirable to monitor package file placement minutely, any package large enough to warrent removal for disk space reasons can be installed in /opt as detailed by the FHS (perhaps in /opt/foo-x.x with a link from /opt/foo), and new releases can usually be installed over the old, although major upgrades and libraries are generally best done by rebuilding the system from the bottom up.
  • RPM, the Redhat Package Manager, is used by a number of distributions. It is available from https://rpm.org/, and there is an RPM Hint to help with installation.
  • There are several implementations of symlink style package management:
  • The NetBSD package manager, pkgsrc, is available on other systems including Linux. It is at ftp://ftp.netbsd.org/pub/pkgsrc/stable/.
  • Originally based on a script written by LFS' own Gerard Beekmans, install-log records a list of files installed by a package as the package is installed. It is available from https://install-log.sourceforge.net/.
  • CheckInstall attempts log system calls made by "make install". It is available from https://asic-linux.com.mx/~izto/checkinstall/.
  • pkgutils, used by the CRUX distribution, is available from https://crux.nu/Wiki/FaqPkgUtils.
  • There are some hints available for package managers.

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 5.11 kernel, you have to enable the options for ACPI (Advanced Configuration and Power Interface under Power managerment and ACPI options. For very old 32-bit x86 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.

How do I boot LFS with UEFI?

GRUB can be built for UEFI, but doing so needs several packages beyond the scope of LFS. You can consult the BLFS page for it.

Can I skip a package in Chapter 8 since it's already built in Chapter 6 or 7, and it's functioning properly?

Short answer: no.

Long answer: we want LFS to be "settled down": if some package is rebuilt in the LFS system, the result (libraries and binaries) should be same as the result at the end of the LFS book. In Chapter 6 the tools are cross compiled, where many tests in the configure script can't be done. The "guessed" result will be used, unnecessary workarounds are enabled, or optional features are disabled. The tools in Chapter 7 are built for resolving circular dependencies: many of their optional features depend on packages not built yet and have to be disabled. So rebuilding them in Chapter 8 is necessary.

On the other hand, if you are building Linux for some really tiny platform where you can't build packages in a reasonable time (for example, a 16 MHz ARM), you can cross compile everything in Chapter 6 since Chapter 7 and 8 are not applicable. Or, you can do Chapter 7 and 8 with an emulator like QEMU.

Can I modify GCC code and get rid of /lib64?

Short answer: no.

Long answer: LSB mandates the ELF loader to be at /lib64/ld-linux-x86-64.so.2 on x86-64.

Even longer answer: when the kernel is told to execute a dynamic linked ELF executable, it reads the path to the ELF loader hard-coded in the ELF executable, which is /lib64/ld-linux-x86-64.so.2. So, if it does not exist, LFS won't be able to run any dynamic linked executable compiled elsewhere. For example, executables from commercial software packages (MATLAB or COMSOL) or binaries downloaded from GitHub release page will not run.

Back to the top.

When reading and building LFS

What distribution should I use to start from?

Most relatively recent distributions should be fine. You could consult the Host System Requirements page.

Make sure you have installed and/or updated the development packages. (Look for ones starting in "gcc", "glibc", or "libstdc++" or ending in "-dev" or "-devel".)

If you want to use LFS as your main system and you wish to install it without first installing a distribution, It is also possible to use a live image on dvd or usb stick. All major distributions provide one.

How do I compile a kernel or set up modules?

In /usr/share/doc/linux-x.y.z or wherever you unpacked your kernel source and the help in kernel config tool (make menuconfig), see the Module-HOWTO at https://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
main:
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 $

If you can determine that some warning indicates a real bug in the software, report to the maintainer of 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.

For ARM, consult LFS Fork for ARM (64-bit or 32-bit) (SysV and Systemd), maintained by William Harrington; and another LFS ARM64 Branch (64-bit only, Systemd and SysV [NOT TESTED!]), maintained by Xi Ruoyao.

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.

The resources provided above are quite outdated. You can modify the LFS building process after LFS 10.0 (developed by Pierre Labestie) to cross compile LFS: set $LFS_TGT to the triplet of your target platform, and build cross toolchain in Chapter 5 and temporary tools in Chapter 6 as normal. At the end of Chapter 6, build a kernel and a bootloader for the target. Then copy the temporary system to the target platform, boot it, and continue the building from Chapter 7. Read clfs-ng branch (SysV and Systemd) for details.

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
      like
        stairs
          steps.
  • 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.
  • Classic MacOS (before Mac OS X): 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. Mac OS X follows Unix convention (LF only).

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.

Is there a way to download all current files at one time?

Yes. You can download the file LFS-BOOK-x.y-wget-list https://www.linuxfromscratch.org/lfs/downloads/stable/wget-list. To download all the files, use the version of wget on your host distribution to run:

wget --input-file=LFS-BOOK-x.y-wget-list

Back to the top.

General compilation errors

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.)

configure output shows errors, isn't "gcc -V" wrong?

To determine what is present on the system, the configure scripts try various commands with various command line options. They then take actions depending on the exit code of the commands. Some of those commands may write error messages, and this is what you see, for example with "gcc -V". But the configure script itself has not failed.

Why does GCC reports "Internal Compiler Error" for a "hello world" program?

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. Refer to "configure: loading cache /dev/null" in config.log.

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 https://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 https://www.memtest.org/.

CPU overheating is another common hardware problem. Ensure the cooler is properly installed with thermal paste applied. And, some coolers (especially all-in-one liquid coolers) cannot be configured via BIOS and they need special software (for example, liquidctl to set the parameters correctly. If such a cooler is not properly configured, it can run in a lower speed (or does not run at all). If the cooler is already running at full speed but the CPU still overheats, either upgrade the cooler, or downclock the CPU via BIOS.

If both bad memory and CPU overheating can be ruled out, see the long answer.

"No such file or directory" trying to chroot

Example of this error is:

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

If you are sure $LFS/bin/bash exists, what happens is likely that the path to the dynamic linker path embedded inside the executable is /lib64/ld-linux-x86-64.so.2 (/lib/ld-linux.so.2 for 32-bit), and when one goes to run the binary inside the chroot where /lib64/ld-linux-x86-64.so.2 does not exist yet, the very unhelpful No such file or directory error message is shown.

Check if the symlink $LFS/lib64/ld-linux-x86-64.so.2 (it should target ../lib/ld-linux-x86-64.so.2, or ../lib/ld-linux.so.2 for 32-bit) and/or $LFS/lib (it should target usr/lib) are broken. Note that these symlinks must be relative (i.e. it should be ../lib/ld-linux-x86-64.so.2, not $LFS/lib/ld-linux-x86-64-so.2) so they are still vaild in the chroot environment.

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/sda10 /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/sda10 /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 are recorded 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 grep isn't working. To test if grep is working in the chroot environment, run the following command from inside chroot:

grep -E 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 it happens in the LFS chroot environment, ensure your host kernel supports UNIX 98 pseudo terminal (all not-so-old desktop or server distros should support it), and the virtual kernel file systems have been mounted correctly before entering the chroot environment.

If it happens in the complete system built following the SysV revision of the LFS book, it's likely you've missed the line for the devpts filesystem in /etc/fstab.

./config.status: line 508: 0a1,66: command not found (or any similar message with only numbers different)

Check if config.log contains "configure: loading cache /dev/null". If it's the case, refer to the entry for it.

"configure: loading cache /dev/null" in config.log

If it happens in the LFS chroot environment, it's likely you've forgotten to bind mount /dev to $LFS/dev in "Preparing Virtual Kernel File Systems".

Exit from the chroot environment first. Then run ls -l /dev/null. It should output something like crw-rw-rw- 1 root root 1, 3 {some date} /dev/null. Especially, the first letter c and the numbers 1, 3 must be correct. If not, it means your host distro is somehow broken (it may happen if you used the dangerous rm -rf $LFS/* command or similar when /dev had been bind mounted). For a modern host distro it can be fixed by rebooting (a broken /dev may prevent normal rebooting and you may need to use the reset button). For a very old host distro, you may need to reinstall it (so why not update to a modern one? :)

Now we've known the host distro is sane. Make sure $LFS is correctly set and the LFS partition is mounted first. Use umount -R $LFS/dev to unmount $LFS/dev (in case you've mounted something wrong there), then remove everything in $LFS/dev and follow the "Preparing Virtual Kernel File Systems" section to mount $LFS/dev and $LFS/dev/pts correctly. Once they are mounted, you can reenter the chroot environment and continue.

Back to the top.

Package-specific errors

M4: Assumed value of MB_LEN_MAX wrong

This error message usually indicates that limits.h provided by GCC isn't including limits.h from Glibc as it should be. There is one command as a workaround for limits.h in GCC Pass 1. Do not forget to run the command.

In LFS 10.0 through 11.3, there is another command as the workaround running mkheaders after installing Glibc (Chapter 5). This command has been removed in LFS 12.0. Either running this command building LFS 12.0 or later (likely because of a reuse of old scripts - note that such a reuse is strongly discouraged) or forgetting this command building LFS 10.0 through 11.3 will also lead to this error message.

If you've encountered this issue, untar the GCC tarball again and run the command at the bottom of GCC Pass 1 page to create limits.h. Then if you are building LFS 12.0 or later, run rm -f $LFS/tools/lib/gcc/$LFS_TGT/*/include-fixed/limits.h which would fix the issue in case you've mistakenly run the mkheaders command which does not belong to the LFS version you are building. If you are building LFS 11.0 through 11.3, run the mkheaders command in Chapter 5 Glibc.

Systemd: systemd-networkd.service: Failed to determine user credentials: No such process

It's likely because /etc/passwd for sysv revision is misused in systemd-based system. "No such process" is just the "standard" error message for ESRCH, it's not very helpful for diagnosis of this issue.

Back to the top.

Configuration and booting issues

Kernel panic - not syncing: VFS: Unable to mount root fs on ...

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

  • Did you specify the correct partition in /boot/grub/grub.cfg?
  • 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 ext4 is enabled by default, but others like 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).

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.

And, udev may rename your network devices. For example, eth0 may be renamed to enp4s0. You can run ip link command after booting the LFS system, and examine the output to know the name of your network devices.

irq 9: nobody cared (try booting with the "irqpoll" option)

It may be a bug in the firmware (BIOS) or the drivers in kernel. Some hardware vendors tend to use Windows-specific hacks in their BIOS, which is misinterpreted by Linux kernel and causing this kind of issue.

If you see message like this but your system functions normally, you can ignore it. If the system malfunctions, you can try the combinations of several kernel options to workaround: irqpoll, noapic, pci=nocrs, and i8042.nopnp=1.

And, you can try ACPI DSDT override if you really understand it.

You can always report this kind of issue to Kernel bug tracker, no matter if it's a BIOS bug. The kernel developers want to make Linux runable even if the BIOS has this kind of bug.

LFS system is much slower than the host distro (or another distro)

If the LFS system is slower than another distro but not much slower, it's normal. We focus on building a Linux system from source code and we do nothing to tweak the system for marginal performance improvements. The other distros may enable additional compiler optimizations, tune kernel options (via sysctl), or use other approaches to squeeze more performance out. And, LFS uses a latest GCC release which is likely slower than an old GCC release. A new GCC release often attempts to optimize the target code more heavily (these optimizations will slow down the compiliation, but hopefully make the compiled program faster). So LFS will take more time building a large package (like Linux kernel).

But, if the LFS system is very slow (for example, takes 5 hours to build a kernel while the host distro needs only one hour to build the same kernel with exactly same configuration), it likely indicates a CPU dynamic frequency scaling issue. You can monitor the value of "cpu MHz" in /proc/cpuinfo to see if your CPU is running at a reasonable frequency while a workload (like, building the kernel) is running on the CPU.

If your CPU is running at a much lower frequency than expected (an Intel Core i3 building the kernel but running at only 800 MHz is definitely too slow), try to adjust the setting of "Default CPUFreq governor" in the kernel configuration and rebuild the kernel. The ideal setting should limit the CPU at a low frequency when the system is idle, but boost it to the maximum performance while a workload is running.

Note that a governor may behave differently on different CPUs. For example, the "powersave" governor may work fine for one CPU model, but lock another CPU at 800 MHz no matter if there is a workload running. If you can't (or don't want to spend too much time to) find an ideal setting, use the "performance" governor.