2.1. Introduction

In this chapter, the host tools needed for building LFS are checked and, if necessary, installed. Then a partition which will host the LFS system is prepared. We will create the partition itself, create a file system on it, and mount it.

2.2.1. Hardware

The LFS editors recommend that the system CPU have at least four cores and that the system have at least 8 GB of memory. Older systems that do not meet these requirements will still work, but the time to build packages will be significantly longer than documented.

2.2.2. Software

Your host system should have the following software with the minimum versions indicated. This should not be an issue for most modern Linux distributions.

Also note that many distributions will place software headers into separate packages, often in the form of <package-name>-devel or <package-name>-dev . Be sure to install those if your distribution provides them.

Earlier versions of the listed software packages may work, but have not been tested.

• Bash-3.2 (/bin/sh should be a symbolic or hard link to bash)
• Binutils-2.13.1 (Versions greater than 2.45 are not recommended as they have not been tested)
• Bison-2.7 (/usr/bin/yacc should be a link to bison or a small script that executes bison)
• Coreutils-8.1
• Diffutils-2.8.1
• Findutils-4.2.31
• Gawk-4.0.1 (/usr/bin/awk should be a link to gawk)
• GCC-5.4 including the C++ compiler, g++ (Versions greater than 15.2.0 are not recommended as they have not been tested). C and C++ standard libraries (with headers) must also be present so the C++ compiler can build hosted programs
• Grep-2.5.1a
• Gzip-1.3.1
• Linux Kernel-5.4

The reason for the kernel version requirement is that we specify that version when building glibc in Chapter 5 and Chapter 8, so the workarounds for older kernels are not enabled and the compiled glibc is slightly faster and smaller.

As at Dec 2024, 5.4 is the oldest kernel release still supported by the kernel developers. Some kernel releases older than 5.4 may be still supported by third-party teams, but they are not considered official upstream kernel releases; read https://kernel.org/category/releases.html for the details.

If the host kernel is earlier than 5.4 you will need to replace the kernel with a more up-to-date version. There are two ways you can go about this. First, see if your Linux vendor provides a 5.4 or later kernel package. If so, you may wish to install it. If your vendor doesn't offer an acceptable kernel package, or you would prefer not to install it, you can compile a kernel yourself. Instructions for compiling the kernel and configuring the boot loader (assuming the host uses GRUB) are located in Chapter 10.

We require the host kernel to support UNIX 98 pseudo terminal (PTY). It should be enabled on all desktop or server distros shipping Linux 5.4 or a newer kernel. If you are building a custom host kernel, ensure CONFIG_UNIX98_PTYS is set to y in the kernel configuration.

• M4-1.4.10
• Make-4.0
• Patch-2.5.4
• Perl-5.8.8
• Python-3.4
• Sed-4.1.5
• Tar-1.22
• Texinfo-5.0
• Xz-5.0.0

To see whether your host system has all the appropriate versions, and the ability to compile programs, run the following commands:

cat > version-check.sh << "EOF"
#!/bin/bash
# A script to list version numbers of critical development tools
# If you have tools installed in other directories, adjust PATH here AND
# in ~lfs/.bashrc (section 4.4) as well.
LC_ALL=C
PATH=/usr/bin:/bin
bail() { echo "FATAL: $1"; exit 1; }
grep --version > /dev/null 2> /dev/null || bail "grep does not work"
sed '' /dev/null || bail "sed does not work"

... (73 more lines)

2.3.1. Chapters 1–4

These chapters run commands on the host system. When restarting, be certain of one thing:

• Procedures performed as the root user after Section 2.4 must have the LFS environment variable set FOR THE ROOT USER .

2.3.2. Chapters 5–6

• The /mnt/lfs partition must be mounted.
• These two chapters must be done as user lfs . A su - lfs command must be issued before performing any task in these chapters. If you don't do that, you are at risk of installing packages to the host, and potentially rendering it unusable.
• The procedures in General Compilation Instructions are critical. If there is any doubt a package has been installed correctly, ensure the previously expanded tarball has been removed, then re-extract the package, and complete all the instructions in that section.

2.3.3. Chapters 7–10

• The /mnt/lfs partition must be mounted.
• A few operations, from “Preparing Virtual Kernel File Systems” to “Entering the Chroot Environment,” must be done as the root user, with the LFS environment variable set for the root user.
• When entering chroot, the LFS environment variable must be set for root . The LFS variable is not used after the chroot environment has been entered.
• The virtual file systems must be mounted. This can be done before or after entering chroot by changing to a host virtual terminal and, as root , running the commands in Section 7.3.1, “Mounting and Populating /dev” and Section 7.3.2, “Mounting Virtual Kernel File Systems.”

2.4.1. Other Partition Issues

Requests for advice on system partitioning are often posted on the LFS mailing lists. This is a highly subjective topic.

The default for most distributions is to use the entire drive with the exception of one small swap partition. This is not optimal for LFS for several reasons. It reduces flexibility, makes sharing of data across multiple distributions or LFS builds more difficult, makes backups more time consuming, and can waste disk space through inefficient allocation of file system structures.

2.4.1.1. The Root Partition

A root LFS partition (not to be confused with the /root directory) of twenty gigabytes is a good compromise for most systems. It provides enough space to build LFS and most of BLFS, but is small enough so that multiple partitions can be easily created for experimentation.

2.4.1.2. The Swap Partition

Most distributions automatically create a swap partition. Generally the recommended size of the swap partition is about twice the amount of physical RAM, however this is rarely needed. If disk space is limited, hold the swap partition to two gigabytes and monitor the amount of disk swapping.

If you want to use the hibernation feature (suspend-to-disk) of Linux, it writes out the contents of RAM to the swap partition before turning off the machine. In this case the size of the swap partition should be at least as large as the system's installed RAM.

Swapping is never good. For mechanical hard drives you can generally tell if a system is swapping by just listening to disk activity and observing how the system reacts to commands. With an SSD you will not be able to hear swapping, but you can tell how much swap space is being used by running the top or free programs. Use of an SSD for a swap partition should be avoided if possible. The first reaction to swapping should be to check for an unreasonable command such as trying to edit a five gigabyte file. If swapping becomes a normal occurrence, the best solution is to purchase more RAM for your system.

2.4.1.3. The Grub Bios Partition

If the boot disk has been partitioned with a GUID Partition Table (GPT), then a small, typically 1 MB, partition must be created if it does not already exist. This partition is not formatted, but must be available for GRUB to use during installation of the boot loader. This partition will normally be labeled 'BIOS Boot' if using fdisk or have a code of EF02 if using the gdisk command.

2.4.1.4. Convenience Partitions

There are several other partitions that are not required, but should be considered when designing a disk layout. The following list is not comprehensive, but is meant as a guide.

• /boot – Highly recommended. Use this partition to store kernels and other booting information. To minimize potential boot problems with larger disks, make this the first physical partition on your first disk drive. A partition size of 200 megabytes is adequate.
• /boot/efi – The EFI System Partition, which is needed for booting the system with UEFI. Read the BLFS page for details.
• /home – Highly recommended. Share your home directory and user customization across multiple distributions or LFS builds. The size is generally fairly large and depends on available disk space.
• /usr – In LFS, /bin , /lib , and /sbin are symlinks to their counterparts in /usr . So /usr contains all the binaries needed for the system to run. For LFS a separate partition for /usr is normally not needed. If you create it anyway, you should make a partition large enough to fit all the programs and libraries in the system. The root partition can be very small (maybe just one gigabyte) in this configuration, so it's suitable for a thin client or diskless workstation (where /usr is mounted from a remote server). However, you should be aware that an initramfs (not covered by LFS) will be needed to boot a system with a separate /usr partition.
• /opt – This directory is most useful for BLFS, where multiple large packages like KDE or Texlive can be installed without embedding the files in the /usr hierarchy. If used, 5 to 10 gigabytes is generally adequate.
• /tmp – A separate /tmp partition is rare, but useful if configuring a thin client. This partition, if used, will usually not need to exceed a couple of gigabytes. If you have enough RAM, you can mount a tmpfs on /tmp to make access to temporary files faster.
• /usr/src – This partition is very useful for providing a location to store BLFS source files and share them across LFS builds. It can also be used as a location for building BLFS packages. A reasonably large partition of 30-50 gigabytes provides plenty of room.

Any separate partition that you want automatically mounted when the system starts must be specified in the /etc/fstab file. Details about how to specify partitions will be discussed in Section 10.2, “Creating the /etc/fstab File”.