Sets the keyboard flags and Light Emitting Diodes (LEDs) |
|
|
Defines the keyboard meta-key handling |
|
|
Sets the console color map in all virtual terminals |
|
|
Shows the current EGA/VGA console screen font |
|
|
Reports the scancodes, keycodes, and ASCII codes of the keys pressed on the keyboard |
|
|
Puts the keyboard and console in UNICODE mode [Don't use this program unless your keymap file is in the ISO-8859-1 encoding. For other encodings, this utility produces incorrect results.] |
|
|
Reverts keyboard and console from UNICODE mode |
The Libpipeline package contains a library for manipulating pipelines of subprocesses in a flexible and convenient way.
Prepare Libpipeline for compilation:
./configure --prefix=/usr
Compile the package:
make
To test the results, issue:
make check
Install the package:
make install
The Make package contains a program for compiling packages.
Again, work around an error caused by glibc-2.27:
sed -i '211,217 d; 219,229 d; 232 d' glob/glob.c
Prepare Make for compilation:
./configure --prefix=/usr
Compile the package:
make
The test suite needs to know where supporting perl files are located. We use an envronment variable to accomplish this. To test the results, issue:
make PERL5LIB=$PWD/tests/ check
Install the package:
make install
The Patch package contains a program for modifying or creating files by applying a “patch” file typically created by the diff program.
Prepare Patch for compilation:
./configure --prefix=/usr
Compile the package:
make
To test the results, issue:
make check
Install the package:
make install
The Sysklogd package contains programs for logging system messages, such as those given by the kernel when unusual things happen.
First, fix problems that causes a segmentation fault under some conditions in klogd and fix an obsolete program construct:
sed -i '/Error loading kernel symbols/{n;n;d}' ksym_mod.c sed -i 's/union wait/int/' syslogd.c
Compile the package:
make
This package does not come with a test suite.
Install the package:
make BINDIR=/sbin install
Create a new /etc/syslog.conf
file by running the following:
cat > /etc/syslog.conf << "EOF"
# Begin /etc/syslog.conf
auth,authpriv.* -/var/log/auth.log
*.*;auth,authpriv.none -/var/log/sys.log
daemon.* -/var/log/daemon.log
kern.* -/var/log/kern.log
mail.* -/var/log/mail.log
user.* -/var/log/user.log
*.emerg *
# End /etc/syslog.conf
EOF
|
A system daemon for intercepting and logging kernel messages |
|
|
Logs the messages that system programs offer for logging [Every logged message contains at least a date stamp and a hostname, and normally the program's name too, but that depends on how trusting the logging daemon is told to be.] |
The Sysvinit package contains programs for controlling the startup, running, and shutdown of the system.
First, apply a patch that removes several programs installed by other packages, clarifies a message, and fixes a compiler warning:
patch -Np1 -i ../sysvinit-2.88dsf-consolidated-1.patch
Compile the package:
make -C src
This package does not come with a test suite.
Install the package:
make -C src install
|
Logs boot messages to a log file |
|
|
Run a command with fstab-encoded arguments |
|
|
Normally invokes shutdown with the
|
|
|
The first process to be started when the kernel has initialized the hardware which takes over the boot process and starts all the proceses specified in its configuration file |
|
|
Sends a signal to all processes, except the processes in its own session so it will not kill its parent shell |
|
|
Tells the kernel to halt the system and switch off the computer (see halt) |
|
|
Tells the kernel to reboot the system (see halt) |
|
|
Reports the previous and the current run-level, as
noted in the last run-level record in |
|
|
Brings the system down in a secure way, signaling all processes and notifying all logged-in users |
|
|
Tells init which run-level to change to |
The Eudev package contains programs for dynamic creation of device nodes.
First, fix a test script:
sed -r -i 's|/usr(/bin/test)|\1|' test/udev-test.pl
Next, add a workaround to prevent the /tools directory from being hard coded into Eudev binary files library locations:
cat > config.cache << "EOF" HAVE_BLKID=1 BLKID_LIBS="-lblkid" BLKID_CFLAGS="-I/tools/include" EOF
Prepare Eudev for compilation:
./configure --prefix=/usr \ --bindir=/sbin \ --sbindir=/sbin \ --libdir=/usr/lib \ --sysconfdir=/etc \ --libexecdir=/lib \ --with-rootprefix= \ --with-rootlibdir=/lib \ --enable-manpages \ --disable-static \ --config-cache
Compile the package:
LIBRARY_PATH=/tools/lib make
The LIBRARY_PATH variable here and the LD_LIBRARY_PATH variable below are needed to allow the use of libraries that were installed in /tools, but have not yet been installed in the main system. LIBRARY_PATH is used to find libraries during the linking process. LD_LIBRARY_PATH is used to find libraries during program execution.
Create some directories now that are needed for tests, but will also be used as a part of installation:
mkdir -pv /lib/udev/rules.d mkdir -pv /etc/udev/rules.d
To test the results, issue:
make LD_LIBRARY_PATH=/tools/lib check
Install the package:
make LD_LIBRARY_PATH=/tools/lib install
Install some custom rules and support files useful in an LFS environment:
tar -xvf ../udev-lfs-20171102.tar.bz2 make -f udev-lfs-20171102/Makefile.lfs install
Information about hardware devices is maintained in the
/etc/udev/hwdb.d
and
/lib/udev/hwdb.d
directories.
Eudev needs that information
to be compiled into a binary database /etc/udev/hwdb.bin
. Create the initial
database:
LD_LIBRARY_PATH=/tools/lib udevadm hwdb --update
This command needs to be run each time the hardware information is updated.
|
Generic udev administration tool: controls the udevd daemon, provides info from the Udev database, monitors uevents, waits for uevents to finish, tests Udev configuration, and triggers uevents for a given device |
|
|
A daemon that listens for uevents on the netlink socket, creates devices and runs the configured external programs in response to these uevents |
|
|
A library interface to udev device information |
|
|
Contains Udev configuration files, device permissions, and rules for device naming |
The Util-linux package contains miscellaneous utility programs. Among them are utilities for handling file systems, consoles, partitions, and messages.
The FHS recommends using the /var/lib/hwclock
directory instead of the
usual /etc
directory as the
location for the adjtime
file.
First create a directory to enable storage for the
hwclock
program:
mkdir -pv /var/lib/hwclock
Prepare Util-linux for compilation:
./configure ADJTIME_PATH=/var/lib/hwclock/adjtime \ --docdir=/usr/share/doc/util-linux-2.31.1 \ --disable-chfn-chsh \ --disable-login \ --disable-nologin \ --disable-su \ --disable-setpriv \ --disable-runuser \ --disable-pylibmount \ --disable-static \ --without-python \ --without-systemd \ --without-systemdsystemunitdir
The --disable and --without options prevent warnings about building components that require packages not in LFS or are inconsistent with programs installed by other packages.
Compile the package:
make
If desired, run the test suite as a non-root user:
Running the test suite as the root user can be harmful to your system. To run it, the CONFIG_SCSI_DEBUG option for the kernel must be available in the currently running system, and must be built as a module. Building it into the kernel will prevent booting. For complete coverage, other BLFS packages must be installed. If desired, this test can be run after rebooting into the completed LFS system and running:
bash tests/run.sh --srcdir=$PWD --builddir=$PWD
chown -Rv nobody . su nobody -s /bin/bash -c "PATH=$PATH make -k check"
One test, fincore/count, may fail in the initial chroot environment but will pass if the test is rerun after the LFS system is complete.
Install the package:
make install
|
Informs the Linux kernel of new partitions |
|
|
Opens a tty port, prompts for a login name, and then invokes the login program |
|
|
Discards sectors on a device |
|
|
A command line utility to locate and print block device attributes |
|
|
Allows users to call block device ioctls from the command line |
|
|
Displays a simple calendar |
|
|
Manipulates the partition table of the given device |
|
|
Modifies the state of CPUs |
|
|
Manipulates real-time attributes of a process |
|
|
Filters out reverse line feeds |
|
|
Filters nroff output for terminals that lack some capabilities, such as overstriking and half-lines |
|
|
Filters out the given columns |
|
|
Formats a given file into multiple columns |
|
|
Sets the function of the Ctrl+Alt+Del key combination to a hard or a soft reset |
|
|
Asks the Linux kernel to remove a partition |
|
|
Dumps the kernel boot messages |
|
|
Ejects removable media |
|
|
Preallocates space to a file |
|
|
Low-level formats a floppy disk |
|
|
Manipulates the partition table of the given device |
|
|
Finds a file system by label or Universally Unique Identifier (UUID) |
|
|
Is a command line interface to the libmount library for work with mountinfo, fstab and mtab files |
|
|
Acquires a file lock and then executes a command with the lock held |
|
|
Is used to check, and optionally repair, file systems |
|
|
Performs a consistency check on the Cramfs file system on the given device |
|
|
Performs a consistency check on the Minix file system on the given device |
|
|
Is a very simple wrapper around FIFREEZE/FITHAW ioctl kernel driver operations |
|
|
Discards unused blocks on a mounted filesystem |
|
|
Parses options in the given command line |
|
|
Dumps the given file in hexadecimal or in another given format |
|
|
Reads or sets the system's hardware clock, also called the Real-Time Clock (RTC) or Basic Input-Output System (BIOS) clock |
|
|
A symbolic link to setarch |
|
|
Gets or sets the io scheduling class and priority for a program |
|
|
Creates various IPC resources |
|
|
Removes the given Inter-Process Communication (IPC) resource |
|
|
Provides IPC status information |
|
|
Reports the size of an iso9660 file system |
|
|
Sends signals to processes |
|
|
Shows which users last logged in (and out),
searching back through the |
|
|
Shows the failed login attempts, as logged in
|
|
|
Attaches a line discipline to a serial line |
|
|
A symbolic link to setarch |
|
|
A symbolic link to setarch |
|
|
Enters the given message into the system log |
|
|
Displays lines that begin with the given string |
|
|
Sets up and controls loop devices |
|
|
Lists information about all or selected block devices in a tree-like format |
|
|
Prints CPU architecture information |
|
|
Prints information on IPC facilities currently employed in the system |
|
|
Lists local system locks |
|
|
Lists information about users, groups and system accounts |
|
|
Generates magic cookies (128-bit random hexadecimal numbers) for xauth |
|
|
Controls whether other users can send messages to the current user's terminal |
|
|
Builds a file system on a device (usually a hard disk partition) |
|
|
Creates a Santa Cruz Operations (SCO) bfs file system |
|
|
Creates a cramfs file system |
|
|
Creates a Minix file system |
|
|
Initializes the given device or file to be used as a swap area |
|
|
A filter for paging through text one screen at a time |
|
|
Attaches the file system on the given device to a specified directory in the file-system tree |
|
|
Checks if the directory is a mountpoint |
|
|
Shows the symbolic links in the given pathnames |
|
|
Runs a program with namespaces of other processes |
|
|
Tells the kernel about the presence and numbering of on-disk partitions |
|
|
Displays a text file one screen full at a time |
|
|
Makes the given file system the new root file system of the current process |
|
|
Get and set a process' resource limits |
|
|
Bind a Linux raw character device to a block device |
|
|
Reads kernel profiling information |
|
|
Renames the given files, replacing a given string with another |
|
|
Alters the priority of running processes |
|
|
Asks the Linux kernel to resize a partition |
|
|
Reverses the lines of a given file |
|
|
Used to enter a system sleep state until specified wakeup time |
|
|
Makes a typescript of a terminal session |
|
|
Plays back typescripts using timing information |
|
|
Changes reported architecture in a new program environment and sets personality flags |
|
|
Runs the given program in a new session |
|
|
Sets terminal attributes |
|
|
A disk partition table manipulator |
|
|
Allows |
|
|
Allows to change swaparea UUID and label |
|
|
Disables devices and files for paging and swapping |
|
|
Enables devices and files for paging and swapping and lists the devices and files currently in use |
|
|
Switches to another filesystem as the root of the mount tree |
|
|
Tracks the growth of a log file; displays the last 10 lines of a log file, then continues displaying any new entries in the log file as they are created |
|
|
Retrieves or sets a process' CPU affinity |
|
|
A filter for translating underscores into escape sequences indicating underlining for the terminal in use |
|
|
Disconnects a file system from the system's file tree |
|
|
A symbolic link to setarch |
|
|
Runs a program with some namespaces unshared from parent |
|
|
Displays the content of the given login file in a more user-friendly format |
|
|
A daemon used by the UUID library to generate time-based UUIDs in a secure and guaranteed-unique fashion |
|
|
Creates new UUIDs. Each new UUID can reasonably be considered unique among all UUIDs created, on the local system and on other systems, in the past and in the future |
|
|
Displays the contents of a file or, by default, its standard input, on the terminals of all currently logged in users |
|
|
Shows hardware watchdog status |
|
|
Reports the location of the binary, source, and man page for the given command |
|
|
Wipes a filesystem signature from a device |
|
|
A symbolic link to setarch |
|
|
A program to set up and control zram (compressed ram disk) devices |
|
|
Contains routines for device identification and token extraction |
|
|
Contains routines for manipulating partition tables |
|
|
Contains routines for block device mounting and unmounting |
|
|
Contains routines for aiding screen output in tabular form |
|
|
Contains routines for generating unique identifiers for objects that may be accessible beyond the local system |
The Man-DB package contains programs for finding and viewing man pages.
Prepare Man-DB for compilation:
./configure --prefix=/usr \ --docdir=/usr/share/doc/man-db-2.8.1 \ --sysconfdir=/etc \ --disable-setuid \ --enable-cache-owner=bin \ --with-browser=/usr/bin/lynx \ --with-vgrind=/usr/bin/vgrind \ --with-grap=/usr/bin/grap \ --with-systemdtmpfilesdir=
The meaning of the configure options:
--disable-setuid
This disables making the man program setuid to
user man
.
--enable-cache-owner=bin
This makes the system-wide cache files be owned by user bin.
--with-...
These three parameters are used to set some default programs. lynx is a text-based web browser (see BLFS for installation instructions), vgrind converts program sources to Groff input, and grap is useful for typesetting graphs in Groff documents. The vgrind and grap programs are not normally needed for viewing manual pages. They are not part of LFS or BLFS, but you should be able to install them yourself after finishing LFS if you wish to do so.
Compile the package:
make
To test the results, issue:
make check
Install the package:
make install
The following table shows the character set that Man-DB
assumes manual pages installed under /usr/share/man/<ll>
will be encoded
with. In addition to this, Man-DB correctly determines if
manual pages installed in that directory are UTF-8 encoded.
Table 6.1. Expected character encoding of legacy 8-bit manual pages
| Language (code) | Encoding | Language (code) | Encoding |
|---|---|---|---|
| Danish (da) | ISO-8859-1 | Croatian (hr) | ISO-8859-2 |
| German (de) | ISO-8859-1 | Hungarian (hu) | ISO-8859-2 |
| English (en) | ISO-8859-1 | Japanese (ja) | EUC-JP |
| Spanish (es) | ISO-8859-1 | Korean (ko) | EUC-KR |
| Estonian (et) | ISO-8859-1 | Lithuanian (lt) | ISO-8859-13 |
| Finnish (fi) | ISO-8859-1 | Latvian (lv) | ISO-8859-13 |
| French (fr) | ISO-8859-1 | Macedonian (mk) | ISO-8859-5 |
| Irish (ga) | ISO-8859-1 | Polish (pl) | ISO-8859-2 |
| Galician (gl) | ISO-8859-1 | Romanian (ro) | ISO-8859-2 |
| Indonesian (id) | ISO-8859-1 | Russian (ru) | KOI8-R |
| Icelandic (is) | ISO-8859-1 | Slovak (sk) | ISO-8859-2 |
| Italian (it) | ISO-8859-1 | Slovenian (sl) | ISO-8859-2 |
| Norwegian Bokmal (nb) | ISO-8859-1 | Serbian Latin (sr@latin) | ISO-8859-2 |
| Dutch (nl) | ISO-8859-1 | Serbian (sr) | ISO-8859-5 |
| Norwegian Nynorsk (nn) | ISO-8859-1 | Turkish (tr) | ISO-8859-9 |
| Norwegian (no) | ISO-8859-1 | Ukrainian (uk) | KOI8-U |
| Portuguese (pt) | ISO-8859-1 | Vietnamese (vi) | TCVN5712-1 |
| Swedish (sv) | ISO-8859-1 | Simplified Chinese (zh_CN) | GBK |
| Belarusian (be) | CP1251 | Simplified Chinese, Singapore (zh_SG) | GBK |
| Bulgarian (bg) | CP1251 | Traditional Chinese, Hong Kong (zh_HK) | BIG5HKSCS |
| Czech (cs) | ISO-8859-2 | Traditional Chinese (zh_TW) | BIG5 |
| Greek (el) | ISO-8859-7 |
Manual pages in languages not in the list are not supported.
|
Dumps the whatis database contents in human-readable form |
|
|
Searches the whatis database and displays the short descriptions of system commands that contain a given string |
|
|
Creates or updates the pre-formatted manual pages |
|
|
Displays one-line summary information about a given manual page |
|
|
Formats and displays the requested manual page |
|
|
Creates or updates the whatis database |
|
|
Displays the contents of $MANPATH or (if $MANPATH is not set) a suitable search path based on the settings in man.conf and the user's environment |
|
|
Searches the whatis database and displays the short descriptions of system commands that contain the given keyword as a separate word |
|
|
Contains run-time support for man |
|
|
Contains run-time support for man |
The Tar package contains an archiving program.
Prepare Tar for compilation:
FORCE_UNSAFE_CONFIGURE=1 \ ./configure --prefix=/usr \ --bindir=/bin
The meaning of the configure options:
FORCE_UNSAFE_CONFIGURE=1
This forces the test for mknod
to be run as root. It is
generally considered dangerous to run this test as the
root user, but as it is being run on a system that has
only been partially built, overriding it is OK.
Compile the package:
make
To test the results (about 1 SBU), issue:
make check
One test, link mismatch, is known to fail.
Install the package:
make install make -C doc install-html docdir=/usr/share/doc/tar-1.30
The Texinfo package contains programs for reading, writing, and converting info pages.
Prepare Texinfo for compilation:
./configure --prefix=/usr --disable-static
The meaning of the configure options:
--disable-static
In this case, the top-level configure script will
complain that this is an unrecognized option, but the
configure script for XSParagraph recognizes it and uses
it to disable installing a static XSParagraph.a
to /usr/lib/texinfo
.
Compile the package:
make
To test the results, issue:
make check
Install the package:
make install
Optionally, install the components belonging in a TeX installation:
make TEXMF=/usr/share/texmf install-tex
The meaning of the make parameter:
TEXMF=/usr/share/texmf
The TEXMF
makefile variable
holds the location of the root of the TeX tree if, for
example, a TeX package will be installed later.
The Info documentation system uses a plain text file to hold
its list of menu entries. The file is located at /usr/share/info/dir
. Unfortunately, due to
occasional problems in the Makefiles of various packages, it
can sometimes get out of sync with the info pages installed
on the system. If the /usr/share/info/dir
file ever needs to be
recreated, the following optional commands will accomplish
the task:
pushd /usr/share/info rm -v dir for f in * do install-info $f dir 2>/dev/null done popd
|
Used to read info pages which are similar to man pages, but often go much deeper than just explaining all the available command line options [For example, compare man bison and info bison.] |
|
|
Used to install info pages; it updates entries in the info index file |
|
|
Translates the given Texinfo source documents into info pages, plain text, or HTML |
|
|
Used to format the given Texinfo document into a Portable Document Format (PDF) file |
|
|
Converts Pod to Texinfo format |
|
|
Translate Texinfo source documentation to various other formats |
|
|
Used to format the given Texinfo document into a device-independent file that can be printed |
|
|
Used to format the given Texinfo document into a Portable Document Format (PDF) file |
|
|
Used to sort Texinfo index files |
The Vim package contains a powerful text editor.
If you prefer another editor—such as Emacs, Joe, or Nano—please refer to http://www.linuxfromscratch.org/blfs/view/8.2/postlfs/editors.html for suggested installation instructions.
First, change the default location of the vimrc
configuration file to /etc
:
echo '#define SYS_VIMRC_FILE "/etc/vimrc"' >> src/feature.h
Disable a test that fails:
sed -i '/call/{s/split/xsplit/;s/303/492/}' src/testdir/test_recover.vim
Prepare Vim for compilation:
./configure --prefix=/usr
Compile the package:
make
To test the results, issue:
make -j1 test &> vim-test.log
The test suite outputs a lot of binary data to the screen. This can cause issues with the settings of the current terminal. The problem can be avoided by redirecting the output to a log file as shown above. A successful test will result in the words "ALL DONE" in the log file at completion.
Install the package:
make install
Many users are used to using vi instead of vim. To allow execution of vim when users habitually enter vi, create a symlink for both the binary and the man page in the provided languages:
ln -sv vim /usr/bin/vi for L in /usr/share/man/{,*/}man1/vim.1; do ln -sv vim.1 $(dirname $L)/vi.1 done
By default, Vim's documentation is installed in /usr/share/vim
. The following symlink
allows the documentation to be accessed via /usr/share/doc/vim-8.0.586
, making it
consistent with the location of documentation for other
packages:
ln -sv ../vim/vim80/doc /usr/share/doc/vim-8.0.586
If an X Window System is going to be installed on the LFS system, it may be necessary to recompile Vim after installing X. Vim comes with a GUI version of the editor that requires X and some additional libraries to be installed. For more information on this process, refer to the Vim documentation and the Vim installation page in the BLFS book at http://www.linuxfromscratch.org/blfs/view/8.2/postlfs/vim.html.
By default, vim runs in vi-incompatible mode. This may be new to users who have used other editors in the past. The “nocompatible” setting is included below to highlight the fact that a new behavior is being used. It also reminds those who would change to “compatible” mode that it should be the first setting in the configuration file. This is necessary because it changes other settings, and overrides must come after this setting. Create a default vim configuration file by running the following:
cat > /etc/vimrc << "EOF"
" Begin /etc/vimrc
" Ensure defaults are set before customizing settings, not after
source $VIMRUNTIME/defaults.vim
let skip_defaults_vim=1
set nocompatible
set backspace=2
set mouse=
syntax on
if (&term == "xterm") || (&term == "putty")
set background=dark
endif
" End /etc/vimrc
EOF
The set nocompatible
setting makes vim behave in a more useful
way (the default) than the vi-compatible manner. Remove the
“no” to keep the old vi behavior. The set backspace=2
setting allows
backspacing over line breaks, autoindents, and the start of
insert. The syntax on
parameter enables vim's syntax highlighting. The set mouse=
setting enables
proper pasting of text with the mouse when working in chroot
or over a remote connection. Finally, the if statement with the set background=dark
setting
corrects vim's
guess about the background color of some terminal emulators.
This gives the highlighting a better color scheme for use on
the black background of these programs.
Documentation for other available options can be obtained by running the following command:
vim -c ':options'
By default, Vim only installs spell files for the English
language. To install spell files for your preferred
language, download the *.spl
and optionally, the *.sug
files for your language and character encoding from
ftp://ftp.vim.org/pub/vim/runtime/spell/
and save them to /usr/share/vim/vim80/spell/
.
To use these spell files, some configuration in
/etc/vimrc
is needed, e.g.:
set spelllang=en,ru
set spell
For more information, see the appropriate README file located at the URL above.
|
Starts vim in ex mode |
|
|
Is a restricted version of view; no shell commands can be started and view cannot be suspended |
|
|
Is a restricted version of vim; no shell commands can be started and vim cannot be suspended |
|
|
Link to vim |
|
|
Starts vim in read-only mode |
|
|
Is the editor |
|
|
Edits two or three versions of a file with vim and shows differences |
|
|
Teaches the basic keys and commands of vim |
|
|
Creates a hex dump of the given file; it can also do the reverse, so it can be used for binary patching |
Most programs and libraries are, by default, compiled with
debugging symbols included (with gcc's -g
option). This means that when
debugging a program or library that was compiled with debugging
information included, the debugger can provide not only memory
addresses, but also the names of the routines and variables.
However, the inclusion of these debugging symbols enlarges a program or library significantly. The following is an example of the amount of space these symbols occupy:
A bash binary with debugging symbols: 1200 KB
A bash binary without debugging symbols: 480 KB
Glibc and GCC files (/lib
and /usr/lib
) with
debugging symbols: 87 MB
Glibc and GCC files without debugging symbols: 16 MB
Sizes may vary depending on which compiler and C library were used, but when comparing programs with and without debugging symbols, the difference will usually be a factor between two and five.
Because most users will never use a debugger on their system software, a lot of disk space can be regained by removing these symbols. The next section shows how to strip all debugging symbols from the programs and libraries.
This section is optional. If the intended user is not a programmer and does not plan to do any debugging on the system software, the system size can be decreased by about 90 MB by removing the debugging symbols from binaries and libraries. This causes no inconvenience other than not being able to debug the software fully anymore.
Most people who use the commands mentioned below do not experience any difficulties. However, it is easy to make a typo and render the new system unusable, so before running the strip commands, it is a good idea to make a backup of the LFS system in its current state.
First place the debugging symbols for selected libraries in separate files. This debugging information is needed if running regression tests that use valgrind or gdb later in BLFS.
save_lib="ld-2.27.so libc-2.27.so libpthread-2.27.so libthread_db-1.0.so" cd /lib for LIB in $save_lib; do objcopy --only-keep-debug $LIB $LIB.dbg strip --strip-unneeded $LIB objcopy --add-gnu-debuglink=$LIB.dbg $LIB done save_usrlib="libquadmath.so.0.0.0 libstdc++.so.6.0.24 libmpx.so.2.0.1 libmpxwrappers.so.2.0.1 libitm.so.1.0.0 libcilkrts.so.5.0.0 libatomic.so.1.2.0" cd /usr/lib for LIB in $save_usrlib; do objcopy --only-keep-debug $LIB $LIB.dbg strip --strip-unneeded $LIB objcopy --add-gnu-debuglink=$LIB.dbg $LIB done unset LIB save_lib save_usrlib
Before performing the stripping, take special care to ensure that none of the binaries that are about to be stripped are running. If unsure whether the user entered chroot with the command given in Section 6.4, “Entering the Chroot Environment,” first exit from chroot:
logout
Then reenter it with:
chroot $LFS /tools/bin/env -i \ HOME=/root TERM=$TERM \ PS1='(lfs chroot) \u:\w\$ ' \ PATH=/bin:/usr/bin:/sbin:/usr/sbin \ /tools/bin/bash --login
Now the binaries and libraries can be safely stripped:
/tools/bin/find /usr/lib -type f -name \*.a \ -exec /tools/bin/strip --strip-debug {} ';' /tools/bin/find /lib /usr/lib -type f \( -name \*.so* -a ! -name \*dbg \) \ -exec /tools/bin/strip --strip-unneeded {} ';' /tools/bin/find /{bin,sbin} /usr/{bin,sbin,libexec} -type f \ -exec /tools/bin/strip --strip-all {} ';'
A large number of files will be reported as having their file format not recognized. These warnings can be safely ignored. These warnings indicate that those files are scripts instead of binaries.
Finally, clean up some extra files left around from running tests:
rm -rf /tmp/*
From now on, when reentering the chroot environment after exiting, use the following modified chroot command:
chroot "$LFS" /usr/bin/env -i \ HOME=/root TERM="$TERM" \ PS1='(lfs chroot) \u:\w\$ ' \ PATH=/bin:/usr/bin:/sbin:/usr/sbin \ /bin/bash --login
The reason for this is that the programs in /tools
are no longer needed. Since they are
no longer needed you can delete the /tools
directory if so desired.
Removing /tools
will also
remove the temporary copies of Tcl, Expect, and DejaGNU which
were used for running the toolchain tests. If you need these
programs later on, they will need to be recompiled and
re-installed. The BLFS book has instructions for this (see
http://www.linuxfromscratch.org/blfs/).
If the virtual kernel file systems have been unmounted, either manually or through a reboot, ensure that the virtual kernel file systems are mounted when reentering the chroot. This process was explained in Section 6.2.2, “Mounting and Populating /dev” and Section 6.2.3, “Mounting Virtual Kernel File Systems”.
There were several static libraries that were not suppressed earlier in the chapter in order to satisfy the regression tests in several packages. These libraries are from binutils, bzip2, e2fsprogs, flex, libtool, and zlib. If desired, remove them now:
rm -f /usr/lib/lib{bfd,opcodes}.a rm -f /usr/lib/libbz2.a rm -f /usr/lib/lib{com_err,e2p,ext2fs,ss}.a rm -f /usr/lib/libltdl.a rm -f /usr/lib/libfl.a rm -f /usr/lib/libfl_pic.a rm -f /usr/lib/libz.a
There are also several files installed in the /usr/lib directory with a file name extention of .la. These are "libtool archive" files and generally unneeded on a linux system. None of these are necessary at this point. To remove them, run:
find /usr/lib -name \*.la -delete
For more information about libtool archive files, see the BLFS section "About Libtool Archive (.la) files".
Booting a Linux system involves several tasks. The process must mount both virtual and real file systems, initialize devices, activate swap, check file systems for integrity, mount any swap partitions or files, set the system clock, bring up networking, start any daemons required by the system, and accomplish any other custom tasks needed by the user. This process must be organized to ensure the tasks are performed in the correct order but, at the same time, be executed as fast as possible.
System V is the classic boot process that has been used in Unix and Unix-like systems such as Linux since about 1983. It consists of a small program, init, that sets up basic programs such as login (via getty) and runs a script. This script, usually named rc, controls the execution of a set of additional scripts that perform the tasks required to initialize the system.
The init
program is controlled by the /etc/inittab
file and is organized into run
levels that can be run by the user:
0 — halt
1 — Single user mode
2 — Multiuser, without networking
3 — Full multiuser mode
4 — User definable
5 — Full multiuser mode with display manager
6 — reboot
The usual default run level is 3 or 5.
Established, well understood system.
Easy to customize.
Slower to boot. A medium speed base LFS system takes 8-12 seconds where the boot time is measured from the first kernel message to the login prompt. Network connectivity is typically established about 2 seconds after the login prompt.
Serial processing of boot tasks. This is related to the previous point. A delay in any process such as a file system check, will delay the entire boot process.
Does not directly support advanced features like control groups (cgroups), and per-user fair share scheduling.
Adding scripts requires manual, static sequencing decisions.
The LFS-Bootscripts package contains a set of scripts to start/stop the LFS system at bootup/shutdown. The configuration files and procedures needed to customize the boot process are described in the following sections.
Install the package:
make install
|
Checks the integrity of the file systems before they are mounted (with the exception of journal and network based file systems) |
|
|
Removes files that should not be preserved between
reboots, such as those in |
|
|
Loads the correct keymap table for the desired keyboard layout; it also sets the screen font |
|
|
Contains common functions, such as error and status checking, that are used by several bootscripts |
|
|
Halts the system |
|
|
Stops a network device |
|
|
Initializes a network device |
|
|
Sets up the system's hostname and local loopback device |
|
|
Loads kernel modules listed in |
|
|
Mounts all file systems, except ones that are marked noauto or are network based |
|
|
Mounts virtual kernel file systems, such as
|
|
|
Sets up network interfaces, such as network cards, and sets up the default gateway (where applicable) |
|
|
The master run-level control script; it is responsible for running all the other bootscripts one-by-one, in a sequence determined by the name of the symbolic links being processed |
|
|
Reboots the system |
|
|
Makes sure every process is terminated before the system reboots or halts |
|
|
Resets the kernel clock to local time in case the hardware clock is not set to UTC time |
|
|
Provides the functionality needed to assign a static Internet Protocol (IP) address to a network interface |
|
|
Enables and disables swap files and partitions |
|
|
Loads system configuration values from |
|
|
Starts and stops the system and kernel log daemons |
|
|
A template to create custom bootscripts for other daemons |
|
|
Prepares the |
|
|
Retries failed udev uevents, and copies generated
rules files from |
In Chapter 6, we installed the Udev package when eudev was built. Before we go into the details regarding how this works, a brief history of previous methods of handling devices is in order.
Linux systems in general traditionally used a static device
creation method, whereby a great many device nodes were created
under /dev
(sometimes literally
thousands of nodes), regardless of whether the corresponding
hardware devices actually existed. This was typically done via
a MAKEDEV script,
which contains a number of calls to the mknod program with the
relevant major and minor device numbers for every possible
device that might exist in the world.
Using the Udev method, only those devices which are detected by
the kernel get device nodes created for them. Because these
device nodes will be created each time the system boots, they
will be stored on a devtmpfs
file system (a virtual file system that resides entirely in
system memory). Device nodes do not require much space, so the
memory that is used is negligible.
In February 2000, a new filesystem called devfs
was merged into the 2.3.46 kernel
and was made available during the 2.4 series of stable
kernels. Although it was present in the kernel source itself,
this method of creating devices dynamically never received
overwhelming support from the core kernel developers.
The main problem with the approach adopted by devfs
was the way it handled device
detection, creation, and naming. The latter issue, that of
device node naming, was perhaps the most critical. It is
generally accepted that if device names are allowed to be
configurable, then the device naming policy should be up to a
system administrator, not imposed on them by any particular
developer(s). The devfs
file
system also suffered from race conditions that were inherent
in its design and could not be fixed without a substantial
revision to the kernel. It was marked as deprecated for a
long period – due to a lack of maintenance – and
was finally removed from the kernel in June, 2006.
With the development of the unstable 2.5 kernel tree, later
released as the 2.6 series of stable kernels, a new virtual
filesystem called sysfs
came
to be. The job of sysfs
is to
export a view of the system's hardware configuration to
userspace processes. With this userspace-visible
representation, the possibility of developing a userspace
replacement for devfs
became
much more realistic.
The sysfs
filesystem was
mentioned briefly above. One may wonder how sysfs
knows about the devices present
on a system and what device numbers should be used for
them. Drivers that have been compiled into the kernel
directly register their objects with a sysfs
(devtmpfs internally) as they are
detected by the kernel. For drivers compiled as modules,
this registration will happen when the module is loaded.
Once the sysfs
filesystem
is mounted (on /sys), data which the drivers register with
sysfs
are available to
userspace processes and to udevd for processing (including
modifications to device nodes).
Device files are created by the kernel by the devtmpfs
filesystem. Any driver that
wishes to register a device node will go through the
devtmpfs
(via the driver
core) to do it. When a devtmpfs
instance is mounted on
/dev
, the device node will
initially be created with a fixed name, permissions, and
owner.
A short time later, the kernel will send a uevent to
udevd. Based
on the rules specified in the files within the /etc/udev/rules.d
, /lib/udev/rules.d
, and /run/udev/rules.d
directories,
udevd will
create additional symlinks to the device node, or change
its permissions, owner, or group, or modify the internal
udevd
database entry (name) for that object.
The rules in these three directories are numbered and all
three directories are merged together. If udevd can't find a rule
for the device it is creating, it will leave the
permissions and ownership at whatever devtmpfs
used initially.
Device drivers compiled as modules may have aliases built
into them. Aliases are visible in the output of the
modinfo
program and are usually related to the bus-specific
identifiers of devices supported by a module. For example,
the snd-fm801 driver
supports PCI devices with vendor ID 0x1319 and device ID
0x0801, and has an alias of “pci:v00001319d00000801sv*sd*bc04sc01i*”.
For most devices, the bus driver exports the alias of the
driver that would handle the device via sysfs
. E.g., the /sys/bus/pci/devices/0000:00:0d.0/modalias
file might contain the string “pci:v00001319d00000801sv00001319sd00001319bc04sc01i00”.
The default rules provided with Udev will cause
udevd to call
out to /sbin/modprobe with the
contents of the MODALIAS
uevent
environment variable (which should be the same as the
contents of the modalias
file
in sysfs), thus loading all modules whose aliases match
this string after wildcard expansion.
In this example, this means that, in addition to snd-fm801, the obsolete (and unwanted) forte driver will be loaded if it is available. See below for ways in which the loading of unwanted drivers can be prevented.
The kernel itself is also able to load modules for network protocols, filesystems and NLS support on demand.
There are a few possible problems when it comes to automatically creating device nodes.
Udev will only load a module if it has a bus-specific alias
and the bus driver properly exports the necessary aliases
to sysfs
. In other cases,
one should arrange module loading by other means. With
Linux-4.15.3, Udev is known to load properly-written
drivers for INPUT, IDE, PCI, USB, SCSI, SERIO, and FireWire
devices.
To determine if the device driver you require has the
necessary support for Udev, run modinfo with the module
name as the argument. Now try locating the device directory
under /sys/bus
and check
whether there is a modalias
file there.
If the modalias
file exists
in sysfs
, the driver
supports the device and can talk to it directly, but
doesn't have the alias, it is a bug in the driver. Load the
driver without the help from Udev and expect the issue to
be fixed later.
If there is no modalias
file
in the relevant directory under /sys/bus
, this means that the kernel
developers have not yet added modalias support to this bus
type. With Linux-4.15.3, this is the case with ISA busses.
Expect this issue to be fixed in later kernel versions.
Udev is not intended to load “wrapper” drivers such as snd-pcm-oss and non-hardware drivers such as loop at all.
If the “wrapper” module only enhances
the functionality provided by some other module (e.g.,
snd-pcm-oss enhances
the functionality of snd-pcm by making the sound
cards available to OSS applications), configure
modprobe to
load the wrapper after Udev loads the wrapped module. To do
this, add a “softdep” line to the
corresponding /etc/modprobe.d/
file. For example:
<filename>
.conf
softdep snd-pcm post: snd-pcm-oss
Note that the “softdep” command also allows
pre:
dependencies, or a
mixture of both pre:
and
post:
. See the modprobe.d(5)
manual page for more
information on “softdep” syntax and
capabilities.
If the module in question is not a wrapper and is useful by
itself, configure the modules bootscript to
load this module on system boot. To do this, add the module
name to the /etc/sysconfig/modules
file on a separate
line. This works for wrapper modules too, but is suboptimal
in that case.
Either don't build the module, or blacklist it in a
/etc/modprobe.d/blacklist.conf
file as
done with the forte
module in the example below:
blacklist forte
Blacklisted modules can still be loaded manually with the explicit modprobe command.
This usually happens if a rule unexpectedly matches a device. For example, a poorly-written rule can match both a SCSI disk (as desired) and the corresponding SCSI generic device (incorrectly) by vendor. Find the offending rule and make it more specific, with the help of the udevadm info command.
This may be another manifestation of the previous problem.
If not, and your rule uses sysfs
attributes, it may be a kernel
timing issue, to be fixed in later kernels. For now, you
can work around it by creating a rule that waits for the
used sysfs
attribute and
appending it to the /etc/udev/rules.d/10-wait_for_sysfs.rules
file (create this file if it does not exist). Please notify
the LFS Development list if you do so and it helps.
Further text assumes that the driver is built statically into the kernel or already loaded as a module, and that you have already checked that Udev doesn't create a misnamed device.
Udev has no information needed to create a device node if a
kernel driver does not export its data to sysfs
. This is most common with third
party drivers from outside the kernel tree. Create a static
device node in /lib/udev/devices
with the appropriate
major/minor numbers (see the file devices.txt
inside the kernel
documentation or the documentation provided by the third
party driver vendor). The static device node will be copied
to /dev
by udev.
This is due to the fact that Udev, by design, handles uevents and loads modules in parallel, and thus in an unpredictable order. This will never be “fixed”. You should not rely upon the kernel device names being stable. Instead, create your own rules that make symlinks with stable names based on some stable attributes of the device, such as a serial number or the output of various *_id utilities installed by Udev. See Section 7.4, “Managing Devices” and Section 7.5, “General Network Configuration” for examples.
Additional helpful documentation is available at the following sites:
A Userspace Implementation of devfs
http://www.kroah.com/linux/talks/ols_2003_udev_paper/Reprint-Kroah-Hartman-OLS2003.pdf
The sysfs
Filesystem
http://www.kernel.org/pub/linux/kernel/people/mochel/doc/papers/ols-2005/mochel.pdf
Udev, by default, names network devices according to Firmware/BIOS data or physical characteristics like the bus, slot, or MAC address. The purpose of this naming convention is to ensure that network devices are named consistently and not based on the time the network card was discovered. For example, on a computer having two network cards made by Intel and Realtek, the network card manufactured by Intel may become eth0 and the Realtek card becomes eth1. In some cases, after a reboot the cards get renumbered the other way around.
In the new naming scheme, typical network device names would then be something like enp5s0 or wlp3s0. If this naming convention is not desired, the traditional naming scheme or a custom scheme can be implemented.
The traditional naming scheme using eth0, eth1, etc can be
restored by adding net.ifnames=0
on the
kernel command line. This is most appropriate for those
systems that have only one ethernet device of the same
type. Laptops often have multiple ethernet connections that
are named eth0 and wlan0 and are also candidates for this
method. The command line is passed in the GRUB
configuration file. See Section 8.4.4,
“Creating the GRUB Configuration File”.
The naming scheme can be customized by creating custom Udev rules. A script has been included that generates the initial rules. Generate these rules by running:
bash /lib/udev/init-net-rules.sh
Now, inspect the /etc/udev/rules.d/70-persistent-net.rules
file, to find out which name was assigned to which network
device:
cat /etc/udev/rules.d/70-persistent-net.rules
In some cases such as when MAC addresses have been assigned to a network card manually or in a virtual environment such as Qemu or Xen, the network rules file may not have been generated because addresses are not consistently assigned. In these cases, this method cannot be used.
The file begins with a comment block followed by two lines for each NIC. The first line for each NIC is a commented description showing its hardware IDs (e.g. its PCI vendor and device IDs, if it's a PCI card), along with its driver in parentheses, if the driver can be found. Neither the hardware ID nor the driver is used to determine which name to give an interface; this information is only for reference. The second line is the Udev rule that matches this NIC and actually assigns it a name.
All Udev rules are made up of several keys, separated by commas and optional whitespace. This rule's keys and an explanation of each of them are as follows:
SUBSYSTEM=="net"
- This
tells Udev to ignore devices that are not network
cards.
ACTION=="add"
- This
tells Udev to ignore this rule for a uevent that
isn't an add ("remove" and "change" uevents also
happen, but don't need to rename network interfaces).
DRIVERS=="?*"
- This
exists so that Udev will ignore VLAN or bridge
sub-interfaces (because these sub-interfaces do not
have drivers). These sub-interfaces are skipped
because the name that would be assigned would collide
with their parent devices.
ATTR{address}
- The
value of this key is the NIC's MAC address.
ATTR{type}=="1"
- This
ensures the rule only matches the primary interface
in the case of certain wireless drivers, which create
multiple virtual interfaces. The secondary interfaces
are skipped for the same reason that VLAN and bridge
sub-interfaces are skipped: there would be a name
collision otherwise.
NAME
- The value of this
key is the name that Udev will assign to this
interface.
The value of NAME
is the
important part. Make sure you know which name has been
assigned to each of your network cards before proceeding,
and be sure to use that NAME
value when creating your configuration files below.
Some software that you may want to install later (e.g.,
various media players) expect the /dev/cdrom
and /dev/dvd
symlinks to exist, and to point to
a CD-ROM or DVD-ROM device. Also, it may be convenient to put
references to those symlinks into /etc/fstab
. Udev comes with a script that
will generate rules files to create these symlinks for you,
depending on the capabilities of each device, but you need to
decide which of two modes of operation you wish to have the
script use.
First, the script can operate in “by-path” mode (used by default for USB and FireWire devices), where the rules it creates depend on the physical path to the CD or DVD device. Second, it can operate in “by-id” mode (default for IDE and SCSI devices), where the rules it creates depend on identification strings stored in the CD or DVD device itself. The path is determined by Udev's path_id script, and the identification strings are read from the hardware by its ata_id or scsi_id programs, depending on which type of device you have.
There are advantages to each approach; the correct approach to use will depend on what kinds of device changes may happen. If you expect the physical path to the device (that is, the ports and/or slots that it plugs into) to change, for example because you plan on moving the drive to a different IDE port or a different USB connector, then you should use the “by-id” mode. On the other hand, if you expect the device's identification to change, for example because it may die, and you would replace it with a different device with the same capabilities and which is plugged into the same connectors, then you should use the “by-path” mode.
If either type of change is possible with your drive, then choose a mode based on the type of change you expect to happen more often.
External devices (for example, a USB-connected CD drive) should not use by-path persistence, because each time the device is plugged into a new external port, its physical path will change. All externally-connected devices will have this problem if you write Udev rules to recognize them by their physical path; the problem is not limited to CD and DVD drives.
If you wish to see the values that the Udev scripts will use,
then for the appropriate CD-ROM device, find the
corresponding directory under /sys
(e.g., this can be /sys/block/hdd
) and run a command similar
to the following:
udevadm test /sys/block/hdd
Look at the lines containing the output of various *_id programs. The “by-id” mode will use the ID_SERIAL value if it exists and is not empty, otherwise it will use a combination of ID_MODEL and ID_REVISION. The “by-path” mode will use the ID_PATH value.
If the default mode is not suitable for your situation, then
the following modification can be made to the /etc/udev/rules.d/83-cdrom-symlinks.rules
file, as follows (where mode
is one of “by-id”
or “by-path”):
sed -i -e 's/"write_cd_rules"/"write_cd_rules mode
"/' \
/etc/udev/rules.d/83-cdrom-symlinks.rules
Note that it is not necessary to create the rules files or
symlinks at this time, because you have bind-mounted the
host's /dev
directory into the
LFS system, and we assume the symlinks exist on the host. The
rules and symlinks will be created the first time you boot
your LFS system.
However, if you have multiple CD-ROM devices, then the
symlinks generated at that time may point to different
devices than they point to on your host, because devices are
not discovered in a predictable order. The assignments
created when you first boot the LFS system will be stable, so
this is only an issue if you need the symlinks on both
systems to point to the same device. If you need that, then
inspect (and possibly edit) the generated /etc/udev/rules.d/70-persistent-cd.rules
file after booting, to make sure the assigned symlinks match
what you need.
As explained in Section 7.3,
“Overview of Device and Module Handling”, the
order in which devices with the same function appear in
/dev
is essentially random.
E.g., if you have a USB web camera and a TV tuner, sometimes
/dev/video0
refers to the
camera and /dev/video1
refers
to the tuner, and sometimes after a reboot the order changes
to the opposite one. For all classes of hardware except sound
cards and network cards, this is fixable by creating Udev
rules for custom persistent symlinks. The case of network
cards is covered separately in Section 7.5,
“General Network Configuration”, and sound
card configuration can be found in
BLFS.
For each of your devices that is likely to have this problem
(even if the problem doesn't exist in your current Linux
distribution), find the corresponding directory under
/sys/class
or /sys/block
. For video devices, this may be
/sys/class/video4linux/video
. Figure out the
attributes that identify the device uniquely (usually, vendor
and product IDs and/or serial numbers work):
X
udevadm info -a -p /sys/class/video4linux/video0
Then write rules that create the symlinks, e.g.:
cat > /etc/udev/rules.d/83-duplicate_devs.rules << "EOF"
# Persistent symlinks for webcam and tuner
KERNEL=="video*", ATTRS{idProduct}=="1910", ATTRS{idVendor}=="0d81", \
SYMLINK+="webcam"
KERNEL=="video*", ATTRS{device}=="0x036f", ATTRS{vendor}=="0x109e", \
SYMLINK+="tvtuner"
EOF
The result is that /dev/video0
and /dev/video1
devices still
refer randomly to the tuner and the web camera (and thus
should never be used directly), but there are symlinks
/dev/tvtuner
and /dev/webcam
that always point to the
correct device.
Which interfaces are brought up and down by the network
script usually depends on the files in /etc/sysconfig/
. This directory should
contain a file for each interface to be configured, such as
ifconfig.xyz
, where
“xyz” should describe the network
card. The interface name (e.g. eth0) is usually appropriate.
Inside this file are attributes to this interface, such as
its IP address(es), subnet masks, and so forth. It is
necessary that the stem of the filename be ifconfig.
If the procedure in the previous section was not used, Udev will assign network card interface names based on system physical characteristics such as enp2s1. If you are not sure what your interface name is, you can always run ip link or ls /sys/class/net after you have booted your system.
The following command creates a sample file for the eth0 device with a static IP address:
cd /etc/sysconfig/
cat > ifconfig.eth0 << "EOF"
ONBOOT=yes
IFACE=eth0
SERVICE=ipv4-static
IP=<IP_ADDRESS>
GATEWAY=<IP_ADDRESS>
PREFIX=24
BROADCAST=<IP_ADDRESS>
EOF
The values of these variables must be changed in every file to match the proper setup.
If the ONBOOT
variable is set to
“yes” the System V network script
will bring up the Network Interface Card (NIC) during booting
of the system. If set to anything but “yes”
the NIC will be ignored by the network script and not be
automatically brought up. The interface can be manually
started or stopped with the ifup and ifdown commands.
The IFACE
variable defines the
interface name, for example, eth0. It is required for all
network device configuration files.
The SERVICE
variable defines the
method used for obtaining the IP address. The LFS-Bootscripts
package has a modular IP assignment format, and creating
additional files in the /lib/services/
directory allows other IP
assignment methods. This is commonly used for Dynamic Host
Configuration Protocol (DHCP), which is addressed in the BLFS
book.
The GATEWAY
variable should
contain the default gateway IP address, if one is present. If
not, then comment out the variable entirely.
The PREFIX
variable contains the
number of bits used in the subnet. Each octet in an IP
address is 8 bits. If the subnet's netmask is <IP_ADDRESS>,
then it is using the first three octets (24 bits) to specify
the network number. If the netmask is <IP_ADDRESS>, it
would be using the first 28 bits. Prefixes longer than 24
bits are commonly used by DSL and cable-based Internet
Service Providers (ISPs). In this example (PREFIX=24), the
netmask is <IP_ADDRESS>. Adjust the PREFIX
variable according to your specific
subnet. If omitted, the PREFIX defaults to 24.
For more information see the ifup man page.
The system will need some means of obtaining Domain Name
Service (DNS) name resolution to resolve Internet domain
names to IP addresses, and vice versa. This is best achieved
by placing the IP address of the DNS server, available from
the ISP or network administrator, into /etc/resolv.conf
. Create the file by
running the following:
cat > /etc/resolv.conf << "EOF"
# Begin /etc/resolv.conf
domain <Your Domain Name>
nameserver <IP address of your primary nameserver>
nameserver <IP address of your secondary nameserver>
# End /etc/resolv.conf
EOF
The domain
statement can be
omitted or replaced with a search
statement. See the man page for
resolv.conf for more details.
Replace <IP address of the
nameserver>
with the IP address of the DNS
most appropriate for the setup. There will often be more than
one entry (requirements demand secondary servers for fallback
capability). If you only need or want one DNS server, remove
the second nameserver
line from the file. The IP address may also be a router on
the local network.
The Google Public IPv4 DNS addresses are <IP_ADDRESS> and <IP_ADDRESS>.
During the boot process, the file /etc/hostname
is used for establishing the
system's hostname.
Create the /etc/hostname
file
and enter a hostname by running:
echo "<lfs>
" > /etc/hostname
<lfs>
needs
to be replaced with the name given to the computer. Do not
enter the Fully Qualified Domain Name (FQDN) here. That
information is put in the /etc/hosts
file.
Decide on the IP address, fully-qualified domain name (FQDN),
and possible aliases for use in the /etc/hosts
file. The syntax is:
IP_address myhost.example.org aliases
Unless the computer is to be visible to the Internet (i.e., there is a registered domain and a valid block of assigned IP addresses—most users do not have this), make sure that the IP address is in the private network IP address range. Valid ranges are:
Private Network Address Range Normal Prefix
<IP_ADDRESS> - <IP_ADDRESS> 8
172.x.0.1 - 172.x.255.254 16
192.168.y.1 - 192.168.y.254 24
x can be any number in the range 16-31. y can be any number in the range 0-255.
A valid private IP address could be <IP_ADDRESS>. A valid FQDN for this IP could be lfs.example.org.
Even if not using a network card, a valid FQDN is still required. This is necessary for certain programs to operate correctly.
Create the /etc/hosts
file by
running:
cat > /etc/hosts << "EOF"
# Begin /etc/hosts
<IP_ADDRESS> localhost
<IP_ADDRESS> <FQDN>
<HOSTNAME>
<<IP_ADDRESS>>
<FQDN>
<HOSTNAME>
[alias1] [alias2 ...]
::1 localhost ip6-localhost ip6-loopback
ff02::1 ip6-allnodes
ff02::2 ip6-allrouters
# End /etc/hosts
EOF
The <<IP_ADDRESS>>
,
<FQDN>
, and
<HOSTNAME>
values need to be changed for specific uses or requirements
(if assigned an IP address by a network/system administrator
and the machine will be connected to an existing network).
The optional alias name(s) can be omitted.
Linux uses a special booting facility named SysVinit that is based on a concept of run-levels. It can be quite different from one system to another, so it cannot be assumed that because things worked in one particular Linux distribution, they should work the same in LFS too. LFS has its own way of doing things, but it respects generally accepted standards.
SysVinit (which will be referred to as “init”
from now on) works using a run-levels scheme. There are seven
(numbered 0 to 6) run-levels (actually, there are more
run-levels, but they are for special cases and are generally
not used. See init(8)
for more
details), and each one of those corresponds to the actions
the computer is supposed to perform when it starts up. The
default run-level is 3. Here are the descriptions of the
different run-levels as they are implemented:
0: halt the computer
1: single-user mode
2: multi-user mode without networking
3: multi-user mode with networking
4: reserved for customization, otherwise does the same as 3
5: same as 4, it is usually used for GUI login (like X's xdm or KDE's kdm)
6: reboot the computer
During the kernel initialization, the first program that is
run is either specified on the command line or, by default
init. This
program reads the initialization file /etc/inittab
. Create this file with:
cat > /etc/inittab << "EOF"
# Begin /etc/inittab
id:3:initdefault:
si::sysinit:/etc/rc.d/init.d/rc S
l0:0:wait:/etc/rc.d/init.d/rc 0
l1:S1:wait:/etc/rc.d/init.d/rc 1
l2:2:wait:/etc/rc.d/init.d/rc 2
l3:3:wait:/etc/rc.d/init.d/rc 3
l4:4:wait:/etc/rc.d/init.d/rc 4
l5:5:wait:/etc/rc.d/init.d/rc 5
l6:6:wait:/etc/rc.d/init.d/rc 6
ca:12345:ctrlaltdel:/sbin/shutdown -t1 -a -r now
su:S016:once:/sbin/sulogin
1:2345:respawn:/sbin/agetty --noclear tty1 9600
2:2345:respawn:/sbin/agetty tty2 9600
3:2345:respawn:/sbin/agetty tty3 9600
4:2345:respawn:/sbin/agetty tty4 9600
5:2345:respawn:/sbin/agetty tty5 9600
6:2345:respawn:/sbin/agetty tty6 9600
# End /etc/inittab
EOF
An explanation of this initialization file is in the man page
for inittab. For LFS,
the key command that is run is rc. The initialization file
above will instruct rc to run all the scripts
starting with an S in the /etc/rc.d/rcS.d
directory followed by all
the scripts starting with an S in the /etc/rc.d/rc?.d
directory where the
question mark is specified by the initdefault value.
As a convenience, the rc script reads a library
of functions in /lib/lsb/init-functions
. This library also
reads an optional configuration file, /etc/sysconfig/rc.site
. Any of the system
configuration file parameters described in subsequent
sections can be alternatively placed in this file allowing
consolidation of all system parameters in this one file.
As a debugging convenience, the functions script also logs
all output to /run/var/bootlog
.
Since the /run
directory is a
tmpfs, this file is not persistent across boots, however it
is appended to the more permanent file /var/log/boot.log
at the end of the boot
process.
Changing run-levels is done with init <runlevel>
,
where <runlevel>
is the
target run-level. For example, to reboot the computer, a
user could issue the init
6 command, which is an alias for the
reboot
command. Likewise, init
0 is an alias for the halt command.
There are a number of directories under /etc/rc.d
that look like rc?.d
(where ? is the number of the
run-level) and rcsysinit.d
,
all containing a number of symbolic links. Some begin with
a K, the others
begin with an S, and
all of them have two numbers following the initial letter.
The K means to stop (kill) a service and the S means to
start a service. The numbers determine the order in which
the scripts are run, from 00 to 99—the lower the
number the earlier it gets executed. When init switches to another
run-level, the appropriate services are either started or
stopped, depending on the runlevel chosen.
The real scripts are in /etc/rc.d/init.d
. They do the actual
work, and the symlinks all point to them. K links and S
links point to the same script in /etc/rc.d/init.d
. This is because the
scripts can be called with different parameters like
start
, stop
, restart
, reload
, and status
. When a K link is
encountered, the appropriate script is run with the
stop
argument. When
an S link is encountered, the appropriate script is run
with the start
argument.
There is one exception to this explanation. Links that
start with an S in
the rc0.d
and rc6.d
directories will not cause anything
to be started. They will be called with the parameter
stop
to stop
something. The logic behind this is that when a user is
going to reboot or halt the system, nothing needs to be
started. The system only needs to be stopped.
These are descriptions of what the arguments make the scripts do:
start
The service is started.
stop
The service is stopped.
restart
The service is stopped and then started again.
reload
The configuration of the service is updated. This is used after the configuration file of a service was modified, when the service does not need to be restarted.
status
Tells if the service is running and with which PIDs.
Feel free to modify the way the boot process works (after all, it is your own LFS system). The files given here are an example of how it can be done.
The /etc/rc.d/init.d/udev
initscript starts udevd, triggers any
"coldplug" devices that have already been created by the
kernel and waits for any rules to complete. The script also
unsets the uevent handler from the default of /sbin/hotplug
. This is done because the
kernel no longer needs to call out to an external binary.
Instead udevd
will listen on a netlink socket for uevents that the kernel
raises.
The /etc/rc.d/init.d/udev_retry
initscript takes care of re-triggering events for subsystems
whose rules may rely on filesystems that are not mounted
until the mountfs script is run (in
particular, /usr
and
/var
may cause this). This
script runs after the mountfs script, so those
rules (if re-triggered) should succeed the second time
around. It is configured from the /etc/sysconfig/udev_retry
file; any words
in this file other than comments are considered subsystem
names to trigger at retry time. To find the subsystem of a
device, use udevadm info
--attribute-walk <device> where
<device> is an absolute path in /dev or /sys such as
/dev/sr0 or /sys/class/rtc.
Device drivers compiled as modules may have aliases built
into them. Aliases are visible in the output of the
modinfo
program and are usually related to the bus-specific
identifiers of devices supported by a module. For example,
the snd-fm801 driver
supports PCI devices with vendor ID 0x1319 and device ID
0x0801, and has an alias of “pci:v00001319d00000801sv*sd*bc04sc01i*”.
For most devices, the bus driver exports the alias of the
driver that would handle the device via sysfs
. E.g., the /sys/bus/pci/devices/0000:00:0d.0/modalias
file might contain the string “pci:v00001319d00000801sv00001319sd00001319bc04sc01i00”.
The default rules provided with Udev will cause
udevd to call
out to /sbin/modprobe with the
contents of the MODALIAS
uevent
environment variable (which should be the same as the
contents of the modalias
file
in sysfs), thus loading all modules whose aliases match
this string after wildcard expansion.
In this example, this means that, in addition to snd-fm801, the obsolete (and unwanted) forte driver will be loaded if it is available. See below for ways in which the loading of unwanted drivers can be prevented.
The kernel itself is also able to load modules for network protocols, filesystems and NLS support on demand.
The setclock
script reads the time from the hardware clock, also known as
the BIOS or the Complementary Metal Oxide Semiconductor
(CMOS) clock. If the hardware clock is set to UTC, this
script will convert the hardware clock's time to the local
time using the /etc/localtime
file (which tells the hwclock program which
timezone the user is in). There is no way to detect whether
or not the hardware clock is set to UTC, so this needs to be
configured manually.
The setclock is run via udev when the kernel detects the hardware capability upon boot. It can also be run manually with the stop parameter to store the system time to the CMOS clock.
If you cannot remember whether or not the hardware clock is
set to UTC, find out by running the hwclock --localtime --show
command. This will display what the current time is according
to the hardware clock. If this time matches whatever your
watch says, then the hardware clock is set to local time. If
the output from hwclock is not local time,
chances are it is set to UTC time. Verify this by adding or
subtracting the proper amount of hours for the timezone to
the time shown by hwclock. For example, if
you are currently in the MST timezone, which is also known as
GMT -0700, add seven hours to the local time.
Change the value of the UTC
variable below to a value of 0
(zero) if the hardware clock
is not set to UTC
time.
Create a new file /etc/sysconfig/clock
by running the
following:
cat > /etc/sysconfig/clock << "EOF"
# Begin /etc/sysconfig/clock
UTC=1
# Set this to any options you might need to give to hwclock,
# such as machine hardware clock type for Alphas.
CLOCKPARAMS=
# End /etc/sysconfig/clock
EOF
A good hint explaining how to deal with time on LFS is
available at
http://www.linuxfromscratch.org/hints/downloads/files/time.txt.
It explains issues such as time zones, UTC, and the
TZ
environment variable.
The CLOCKPARAMS and UTC paramaters may be alternatively set
in the /etc/sysconfig/rc.site
file.
This section discusses how to configure the console bootscript that
sets up the keyboard map, console font and console kernel log
level. If non-ASCII characters (e.g., the copyright sign, the
British pound sign and Euro symbol) will not be used and the
keyboard is a U.S. one, much of this section can be skipped.
Without the configuration file, (or equivalent settings in
rc.site
), the console bootscript will do
nothing.
The console
script reads the /etc/sysconfig/console
file for
configuration information. Decide which keymap and screen
font will be used. Various language-specific HOWTOs can also
help with this, see http://www.tldp.org/HOWTO/HOWTO-INDEX/other-lang.html.
If still in doubt, look in the /usr/share/keymaps
and /usr/share/consolefonts
directories for
valid keymaps and screen fonts. Read loadkeys(1)
and setfont(8)
manual pages to determine the
correct arguments for these programs.
The /etc/sysconfig/console
file
should contain lines of the form: VARIABLE="value". The
following variables are recognized:
This variable specifies the log level for kernel messages sent to the console as set by dmesg. Valid levels are from "1" (no messages) to "8". The default level is "7".
This variable specifies the arguments for the loadkeys program, typically, the name of keymap to load, e.g., “it”. If this variable is not set, the bootscript will not run the loadkeys program, and the default kernel keymap will be used. Note that a few keymaps have multiple versions with the same name (cz and its variants in qwerty/ and qwertz/, es in olpc/ and qwerty/, and trf in fgGIod/ and qwerty/). In these cases the parent directory should also be specified (e.g. qwerty/es) to ensure the proper keymap is loaded.
This (rarely used) variable specifies the arguments for the second call to the loadkeys program. This is useful if the stock keymap is not completely satisfactory and a small adjustment has to be made. E.g., to include the Euro sign into a keymap that normally doesn't have it, set this variable to “euro2”.
This variable specifies the arguments for the setfont program. Typically, this includes the font name, “-m”, and the name of the application character map to load. E.g., in order to load the “lat1-16” font together with the “8859-1” application character map (as it is appropriate in the USA), set this variable to “lat1-16 -m 8859-1”. In UTF-8 mode, the kernel uses the application character map for conversion of composed 8-bit key codes in the keymap to UTF-8, and thus the argument of the "-m" parameter should be set to the encoding of the composed key codes in the keymap.
Set this variable to “1”, “yes” or “true” in order to put the console into UTF-8 mode. This is useful in UTF-8 based locales and harmful otherwise.
For many keyboard layouts, there is no stock Unicode keymap in the Kbd package. The console bootscript will convert an available keymap to UTF-8 on the fly if this variable is set to the encoding of the available non-UTF-8 keymap.
Some examples:
For a non-Unicode setup, only the KEYMAP and FONT variables are generally needed. E.g., for a Polish setup, one would use:
cat > /etc/sysconfig/console << "EOF"
# Begin /etc/sysconfig/console
KEYMAP="pl2"
FONT="lat2a-16 -m 8859-2"
# End /etc/sysconfig/console
EOF
As mentioned above, it is sometimes necessary to adjust a stock keymap slightly. The following example adds the Euro symbol to the German keymap:
cat > /etc/sysconfig/console << "EOF"
# Begin /etc/sysconfig/console
KEYMAP="de-latin1"
KEYMAP_CORRECTIONS="euro2"
FONT="lat0-16 -m 8859-15"
# End /etc/sysconfig/console
EOF
The following is a Unicode-enabled example for Bulgarian, where a stock UTF-8 keymap exists:
cat > /etc/sysconfig/console << "EOF"
# Begin /etc/sysconfig/console
UNICODE="1"
KEYMAP="bg_bds-utf8"
FONT="LatArCyrHeb-16"
# End /etc/sysconfig/console
EOF
Due to the use of a 512-glyph LatArCyrHeb-16 font in the previous example, bright colors are no longer available on the Linux console unless a framebuffer is used. If one wants to have bright colors without framebuffer and can live without characters not belonging to his language, it is still possible to use a language-specific 256-glyph font, as illustrated below:
cat > /etc/sysconfig/console << "EOF"
# Begin /etc/sysconfig/console
UNICODE="1"
KEYMAP="bg_bds-utf8"
FONT="cyr-sun16"
# End /etc/sysconfig/console
EOF
The following example illustrates keymap autoconversion from ISO-8859-15 to UTF-8 and enabling dead keys in Unicode mode:
cat > /etc/sysconfig/console << "EOF"
# Begin /etc/sysconfig/console
UNICODE="1"
KEYMAP="de-latin1"
KEYMAP_CORRECTIONS="euro2"
LEGACY_CHARSET="iso-8859-15"
FONT="LatArCyrHeb-16 -m 8859-15"
# End /etc/sysconfig/console
EOF
Some keymaps have dead keys (i.e., keys that don't produce a character by themselves, but put an accent on the character produced by the next key) or define composition rules (such as: “press Ctrl+. A E to get Æ” in the default keymap). Linux-4.15.3 interprets dead keys and composition rules in the keymap correctly only when the source characters to be composed together are not multibyte. This deficiency doesn't affect keymaps for European languages, because there accents are added to unaccented ASCII characters, or two ASCII characters are composed together. However, in UTF-8 mode it is a problem, e.g., for the Greek language, where one sometimes needs to put an accent on the letter “alpha”. The solution is either to avoid the use of UTF-8, or to install the X window system that doesn't have this limitation in its input handling.
For Chinese, Japanese, Korean and some other languages, the Linux console cannot be configured to display the needed characters. Users who need such languages should install the X Window System, fonts that cover the necessary character ranges, and the proper input method (e.g., SCIM, it supports a wide variety of languages).
The /etc/sysconfig/console
file only controls the Linux text console localization. It
has nothing to do with setting the proper keyboard layout
and terminal fonts in the X Window System, with ssh
sessions or with a serial console. In such situations,
limitations mentioned in the last two list items above do
not apply.
At times, it is desired to create files at boot time. For
instance, the /tmp/.ICE-unix
directory may be desired. This can be done by creating an
entry in the /etc/sysconfig/createfiles
configuration
script. The format of this file is embedded in the comments
of the default configuration file.
The sysklogd
script invokes the
syslogd program
as a part of System V initialization. The -m 0
option turns off the
periodic timestamp mark that syslogd writes to the log
files every 20 minutes by default. If you want to turn on
this periodic timestamp mark, edit /etc/sysconfig/rc.site
and define the
variable SYSKLOGD_PARMS to the desired value. For instance,
to remove all parameters, set the variable to a null value:
SYSKLOGD_PARMS=
See man
syslogd
for more options.
The optional /etc/sysconfig/rc.site
file contains
settings that are automatically set for each SystemV boot
script. It can alternatively set the values specified in the
hostname
, console
, and clock
files in the /etc/sysconfig/
directory. If the
associated variables are present in both these separate files
and rc.site
, the values in the
script specific files have precedence.
rc.site
also contains
parameters that can customize other aspects of the boot
process. Setting the IPROMPT variable will enable selective
running of bootscripts. Other options are described in the
file comments. The default version of the file is as follows:
# rc.site # Optional parameters for boot scripts. # Distro Information # These values, if specified here, override the defaults #DISTRO="Linux From Scratch" # The distro name<EMAIL_ADDRESS># Bug report address #DISTRO_MINI="LFS" # Short name used in filenames for distro config # Define custom colors used in messages printed to the screen # Please consult `man console_codes` for more information # under the "ECMA-48 Set Graphics Rendition" section # # Warning: when switching from a 8bit to a 9bit font, # the linux console will reinterpret the bold (1;) to # the top 256 glyphs of the 9bit font. This does # not affect framebuffer consoles # These values, if specified here, override the defaults #BRACKET="\\033[1;34m" # Blue #FAILURE="\\033[1;31m" # Red #INFO="\\033[1;36m" # Cyan #NORMAL="\\033[0;39m" # Grey #SUCCESS="\\033[1;32m" # Green #WARNING="\\033[1;33m" # Yellow # Use a colored prefix # These values, if specified here, override the defaults #BMPREFIX=" " #SUCCESS_PREFIX="${SUCCESS} * ${NORMAL}" #FAILURE_PREFIX="${FAILURE}*****${NORMAL}" #WARNING_PREFIX="${WARNING} *** ${NORMAL}" # Manually seet the right edge of message output (characters) # Useful when resetting console font during boot to override # automatic screen width detection #COLUMNS=120 # Interactive startup #IPROMPT="yes" # Whether to display the interactive boot prompt #itime="3" # The amount of time (in seconds) to display the prompt # The total length of the distro welcome string, without escape codes #wlen=$(echo "Welcome to ${DISTRO}" | wc -c ) #welcome_message="Welcome to ${INFO}${DISTRO}${NORMAL}" # The total length of the interactive string, without escape codes #ilen=$(echo "Press 'I' to enter interactive startup" | wc -c ) #i_message="Press '${FAILURE}I${NORMAL}' to enter interactive startup" # Set scripts to skip the file system check on reboot #FASTBOOT=yes # Skip reading from the console #HEADLESS=yes # Write out fsck progress if yes #VERBOSE_FSCK=no # Speed up boot without waiting for settle in udev #OMIT_UDEV_SETTLE=y # Speed up boot without waiting for settle in udev_retry #OMIT_UDEV_RETRY_SETTLE=yes # Skip cleaning /tmp if yes #SKIPTMPCLEAN=no # For setclock #UTC=1 #CLOCKPARAMS= # For consolelog (Note that the default, 7=debug, is noisy) #LOGLEVEL=7 # For network #HOSTNAME=mylfs # Delay between TERM and KILL signals at shutdown #KILLDELAY=3 # Optional sysklogd parameters #SYSKLOGD_PARMS="-m 0" # Console parameters #UNICODE=1 #KEYMAP="de-latin1" #KEYMAP_CORRECTIONS="euro2" #FONT="lat0-16 -m 8859-15" #LEGACY_CHARSET=
The LFS boot scripts boot and shut down a system in a
fairly efficient manner, but there are a few tweaks that
you can make in the rc.site file to improve speed even more
and to adjust messages according to your preferences. To do
this, adjust the settings in the /etc/sysconfig/rc.site
file above.
During the boot script udev
, there is a call to
udev
settle that requires some time to
complete. This time may or may not be required
depending on devices present in the system. If you
only have simple partitions and a single ethernet
card, the boot process will probably not need to wait
for this command. To skip it, set the variable
OMIT_UDEV_SETTLE=y.
The boot script udev_retry
also runs udev settle by
default. This command is only needed by default if
the /var
directory is
separately mounted. This is because the clock needs
the file /var/lib/hwclock/adjtime
. Other
customizations may also need to wait for udev to
complete, but in many installations it is not needed.
Skip the command by setting the variable
OMIT_UDEV_RETRY_SETTLE=y.
By default, the file system checks are silent. This can appear to be a delay during the bootup process. To turn on the fsck output, set the variable VERBOSE_FSCK=y.
When rebooting, you may want to skip the filesystem
check, fsck, completely.
To do this, either create the file /fastboot
or reboot the system with
the command /sbin/shutdown -f -r
now. On the other hand, you can force
all file systems to be checked by creating
/forcefsck
or running
shutdown with the
-F
parameter
instead of -f
.
Setting the variable FASTBOOT=y will disable fsck during the boot process until it is removed. This is not recommended on a permanent basis.
Normally, all files in the /tmp
directory are deleted at boot
time. Depending on the number of files or directories
present, this can cause a noticeable delay in the
boot process. To skip removing these files set the
variable SKIPTMPCLEAN=y.
During shutdown, the init program sends a TERM signal to each program it has started (e.g. agetty), waits for a set time (default 3 seconds), and sends each process a KILL signal and waits again. This process is repeated in the sendsignals script for any processes that are not shut down by their own scripts. The delay for init can be set by passing a parameter. For example to remove the delay in init, pass the -t0 parameter when shutting down or rebooting (e.g. /sbin/shutdown -t0 -r now). The delay for the sendsignals script can be skipped by setting the parameter KILLDELAY=0.
The shell program /bin/bash (hereafter referred
to as “the
shell”) uses a collection of startup files
to help create an environment to run in. Each file has a
specific use and may affect login and interactive environments
differently. The files in the /etc
directory provide global settings. If an
equivalent file exists in the home directory, it may override
the global settings.
An interactive login shell is started after a successful login,
using /bin/login,
by reading the /etc/passwd
file.
An interactive non-login shell is started at the command-line
(e.g., [prompt]$
/bin/bash). A non-interactive
shell is usually present when a shell script is running. It is
non-interactive because it is processing a script and not
waiting for user input between commands.
For more information, see info bash under the Bash Startup Files and Interactive Shells section.
The files /etc/profile
and
~/.bash_profile
are read when the
shell is invoked as an interactive login shell.
The base /etc/profile
below sets
some environment variables necessary for native language
support. Setting them properly results in:
The output of programs translated into the native language
Correct classification of characters into letters, digits and other classes. This is necessary for bash to properly accept non-ASCII characters in command lines in non-English locales
The correct alphabetical sorting order for the country
Appropriate default paper size
Correct formatting of monetary, time, and date values
Replace <ll>
below with the two-letter code for the desired language (e.g.,
“en”) and <CC>
with the two-letter
code for the appropriate country (e.g., “GB”).
<charmap>
should be replaced with the canonical charmap for your chosen
locale. Optional modifiers such as “@euro”
may also be present.
The list of all locales supported by Glibc can be obtained by running the following command:
locale -a
Charmaps can have a number of aliases, e.g., “ISO-8859-1” is also referred to as
“iso8859-1” and “iso88591”. Some applications cannot
handle the various synonyms correctly (e.g., require that
“UTF-8” is written as “UTF-8”,
not “utf8”), so it is safest in most
cases to choose the canonical name for a particular locale. To
determine the canonical name, run the following command, where
<locale name>
is the output given by locale
-a for your preferred locale (“en_GB.iso88591” in our example).
LC_ALL=<locale name>
locale charmap
For the “en_GB.iso88591” locale, the above command will print:
ISO-8859-1
This results in a final locale setting of “en_GB.ISO-8859-1”. It is important that the locale found using the heuristic above is tested prior to it being added to the Bash startup files:
LC_ALL=<locale name> locale language LC_ALL=<locale name> locale charmap LC_ALL=<locale name> locale int_curr_symbol LC_ALL=<locale name> locale int_prefix
The above commands should print the language name, the character encoding used by the locale, the local currency, and the prefix to dial before the telephone number in order to get into the country. If any of the commands above fail with a message similar to the one shown below, this means that your locale was either not installed in Chapter 6 or is not supported by the default installation of Glibc.
locale: Cannot set LC_* to default locale: No such file or directory
If this happens, you should either install the desired locale using the localedef command, or consider choosing a different locale. Further instructions assume that there are no such error messages from Glibc.
Some packages beyond LFS may also lack support for your chosen locale. One example is the X library (part of the X Window System), which outputs the following error message if the locale does not exactly match one of the character map names in its internal files:
Warning: locale not supported by Xlib, locale set to C
In several cases Xlib expects that the character map will be listed in uppercase notation with canonical dashes. For instance, "ISO-8859-1" rather than "iso88591". It is also possible to find an appropriate specification by removing the charmap part of the locale specification. This can be checked by running the locale charmap command in both locales. For example, one would have to change "de_DE.ISO-8859-15@euro" to "de_DE@euro" in order to get this locale recognized by Xlib.
Other packages can also function incorrectly (but may not necessarily display any error messages) if the locale name does not meet their expectations. In those cases, investigating how other Linux distributions support your locale might provide some useful information.
Once the proper locale settings have been determined, create
the /etc/profile
file:
cat > /etc/profile << "EOF"
# Begin /etc/profile
export LANG=<ll>_<CC>.<charmap><@modifiers>
# End /etc/profile
EOF
The “C” (default) and “en_US” (the recommended one for United States English users) locales are different. “C” uses the US-ASCII 7-bit character set, and treats bytes with the high bit set as invalid characters. That's why, e.g., the ls command substitutes them with question marks in that locale. Also, an attempt to send mail with such characters from Mutt or Pine results in non-RFC-conforming messages being sent (the charset in the outgoing mail is indicated as “unknown 8-bit”). So you can use the “C” locale only if you are sure that you will never need 8-bit characters.
UTF-8 based locales are not supported well by some programs. Work is in progress to document and, if possible, fix such problems, see http://www.linuxfromscratch.org/blfs/view/8.2/introduction/locale-issues.html.
The inputrc
file is the
configuration file for then Readline library, which provides
editing capabilities while the user is entering a line from the
terminal. It works by tranlating keyboard inputs into specific
actions. Readline is used by Bash and most other shells as well
as many other applications.
Most people do not need user-specific functionality so the
command below creates a global /etc/inputrc
used by everyone who logs in. If
you later decide you need to override the defaults on a
per-user basis, you can create a .inputrc
file in the user's home directory
with the modified mappings.
For more information on how to edit the inputrc
file, see info bash under the
Readline Init File
section. info
readline is also a good source of information.
Below is a generic global inputrc
along with comments to explain what the various options do.
Note that comments cannot be on the same line as commands.
Create the file using the following command:
cat > /etc/inputrc << "EOF"
# Begin /etc/inputrc
# Modified by Chris Lynn<EMAIL_ADDRESS># Allow the command prompt to wrap to the next line
set horizontal-scroll-mode Off
# Enable 8bit input
set meta-flag On
set input-meta On
# Turns off 8th bit stripping
set convert-meta Off
# Keep the 8th bit for display
set output-meta On
# none, visible or audible
set bell-style none
# All of the following map the escape sequence of the value
# contained in the 1st argument to the readline specific functions
"\eOd": backward-word
"\eOc": forward-word
# for linux console
"\e[1~": beginning-of-line
"\e[4~": end-of-line
"\e[5~": beginning-of-history
"\e[6~": end-of-history
"\e[3~": delete-char
"\e[2~": quoted-insert
# for xterm
"\eOH": beginning-of-line
"\eOF": end-of-line
# for Konsole
"\e[H": beginning-of-line
"\e[F": end-of-line
# End /etc/inputrc
EOF
The shells
file contains a list
of login shells on the system. Applications use this file to
determine whether a shell is valid. For each shell a single
line should be present, consisting of the shell's path,
relative to the root of the directory structure (/).
For example, this file is consulted by chsh to determine whether an unprivileged user may change the login shell for her own account. If the command name is not listed, the user will be denied of change.
It is a requirement for applications such as GDM which does not populate the face
browser if it can't find /etc/shells
, or FTP daemons which
traditionally disallow access to users with shells not included
in this file.
cat > /etc/shells << "EOF"
# Begin /etc/shells
/bin/sh
/bin/bash
# End /etc/shells
EOF
It is time to make the LFS system bootable. This chapter
discusses creating an fstab
file,
building a kernel for the new LFS system, and installing the
GRUB boot loader so that the LFS system can be selected for
booting at startup.
The /etc/fstab
file is used by
some programs to determine where file systems are to be mounted
by default, in which order, and which must be checked (for
integrity errors) prior to mounting. Create a new file systems
table like this:
cat > /etc/fstab << "EOF"
# Begin /etc/fstab
# file system mount-point type options dump fsck
# order
/dev/<xxx>
/ <fff>
defaults 1 1
/dev/<yyy>
swap swap pri=1 0 0
proc /proc proc nosuid,noexec,nodev 0 0
sysfs /sys sysfs nosuid,noexec,nodev 0 0
devpts /dev/pts devpts gid=5,mode=620 0 0
tmpfs /run tmpfs defaults 0 0
devtmpfs /dev devtmpfs mode=0755,nosuid 0 0
# End /etc/fstab
EOF
Replace <xxx>
,
<yyy>
, and
<fff>
with the
values appropriate for the system, for example, sda2
, sda5
, and
ext4
. For details on the six
fields in this file, see man 5
fstab.
Filesystems with MS-DOS or Windows origin (i.e.: vfat, ntfs,
smbfs, cifs, iso9660, udf) need the “iocharset” mount option in order
for non-ASCII characters in file names to be interpreted
properly. The value of this option should be the same as the
character set of your locale, adjusted in such a way that the
kernel understands it. This works if the relevant character set
definition (found under File systems -> Native Language
Support) has been compiled into the kernel or built as a
module. The “codepage” option is also needed for
vfat and smbfs filesystems. It should be set to the codepage
number used under MS-DOS in your country. E.g., in order to
mount USB flash drives, a ru_RU.KOI8-R user would need the
following in the options portion of its mount line in
/etc/fstab
:
noauto,user,quiet,showexec,iocharset=koi8r,codepage=866
The corresponding options fragment for ru_RU.UTF-8 users is:
noauto,user,quiet,showexec,iocharset=utf8,codepage=866
In the latter case, the kernel emits the following message:
FAT: utf8 is not a recommended IO charset for FAT filesystems,
filesystem will be case sensitive!
This negative recommendation should be ignored, since all other values of the “iocharset” option result in wrong display of filenames in UTF-8 locales.
It is also possible to specify default codepage and iocharset
values for some filesystems during kernel configuration. The
relevant parameters are named “Default NLS
Option” (CONFIG_NLS_DEFAULT)
, “Default Remote NLS
Option” (CONFIG_SMB_NLS_DEFAULT
), “Default codepage for
FAT” (CONFIG_FAT_DEFAULT_CODEPAGE
), and “Default iocharset for
FAT” (CONFIG_FAT_DEFAULT_IOCHARSET
). There is no way
to specify these settings for the ntfs filesystem at kernel
compilation time.
It is possible to make the ext3 filesystem reliable across
power failures for some hard disk types. To do this, add the
barrier=1
mount option to the
appropriate entry in /etc/fstab
.
To check if the disk drive supports this option, run
hdparm on the applicable disk drive. For example, if:
hdparm -I /dev/sda | grep NCQ
returns non-empty output, the option is supported.
Note: Logical Volume Management (LVM) based partitions cannot
use the barrier
option.
The Linux package contains the Linux kernel.
Building the kernel involves a few steps—configuration,
compilation, and installation. Read the README
file in the kernel source tree for
alternative methods to the way this book configures the
kernel.
Prepare for compilation by running the following command:
make mrproper
This ensures that the kernel tree is absolutely clean. The kernel team recommends that this command be issued prior to each kernel compilation. Do not rely on the source tree being clean after un-tarring.
Configure the kernel via a menu-driven interface. For general information on kernel configuration see http://www.linuxfromscratch.org/hints/downloads/files/kernel-configuration.txt. BLFS has some information regarding particular kernel configuration requirements of packages outside of LFS at http://www.linuxfromscratch.org/blfs/view/8.2/longindex.html#kernel-config-index. Additional information about configuring and building the kernel can be found at http://www.kroah.com/lkn/
A good starting place for setting up the kernel configuration is to run make defconfig. This will set the base configuration to a good state that takes your current system architecture into account.
Be sure to enable/disable/set the following features or the system might not work correctly or boot at all:
Device Drivers ---> Generic Driver Options ---> [ ] Support for uevent helper [CONFIG_UEVENT_HELPER] [*] Maintain a devtmpfs filesystem to mount at /dev [CONFIG_DEVTMPFS] Kernel hacking ---> Choose kernel unwinder (Frame pointer unwinder) ---> [CONFIG_UNWINDER_FRAME_POINTER]
There are several other options that may be desired depending on the requirements for the system. For a list of options needed for BLFS packages, see the BLFS Index of Kernel Settings (http://www.linuxfromscratch.org/blfs/view/8.2/longindex.html#kernel-config-index).
If your host hardware is using UEFI, then the 'make defconfig' above should automatically add in some EFI-related kernel options.
In order to allow your LFS kernel to be booted from within your host's UEFI boot environment, your kernel must have this option selected:
Processor type and features ---> [*] EFI stub support [CONFIG_EFI_STUB]
A fuller description of managing UEFI environments from within LFS is covered by the lfs-uefi.txt hint at http://www.linuxfromscratch.org/hints/downloads/files/lfs-uefi.txt.
The rationale for the above configuration items:
Support
for uevent helper
Having this option set may interfere with device management when using Udev/Eudev.
Maintain a
devtmpfs
This will create automated device nodes which are populated by the kernel, even without Udev running. Udev then runs on top of this, managing permissions and adding symlinks. This configuration item is required for all users of Udev/Eudev.
make menuconfig
The meaning of optional make environment variables:
LANG=<host_LANG_value>
LC_ALL=
This establishes the locale setting to the one used on the host. This may be needed for a proper menuconfig ncurses interface line drawing on a UTF-8 linux text console.
If used, be sure to replace <host_LANG_value>
by the value of the $LANG
variable from your host. You can alternatively use
instead the host's value of $LC_ALL
or $LC_CTYPE
.
Alternatively, make
oldconfig may be more appropriate in some
situations. See the README
file
for more information.
If desired, skip kernel configuration by copying the kernel
config file, .config
, from the
host system (assuming it is available) to the unpacked
linux-4.15.3
directory.
However, we do not recommend this option. It is often better
to explore all the configuration menus and create the kernel
configuration from scratch.
Compile the kernel image and modules:
make
If using kernel modules, module configuration in /etc/modprobe.d
may be required.
Information pertaining to modules and kernel configuration is
located in Section 7.3,
“Overview of Device and Module Handling” and
in the kernel documentation in the linux-4.15.3/Documentation
directory. Also,
modprobe.d(5)
may be of
interest.
Install the modules, if the kernel configuration uses them:
make modules_install
After kernel compilation is complete, additional steps are
required to complete the installation. Some files need to be
copied to the /boot
directory.
If the host system has a separate /boot partition, the files copied below should go there. The easiest way to do that is to bind /boot on the host (outside chroot) to /mnt/lfs/boot before proceeding. As the root user in the host system:
mount --bind /boot /mnt/lfs/boot
The path to the kernel image may vary depending on the platform being used. The filename below can be changed to suit your taste, but the stem of the filename should be vmlinuz to be compatible with the automatic setup of the boot process described in the next section. The following command assumes an x86 architecture:
cp -iv arch/x86/boot/bzImage /boot/vmlinuz-4.15.3-lfs-8.2
System.map
is a symbol file for
the kernel. It maps the function entry points of every
function in the kernel API, as well as the addresses of the
kernel data structures for the running kernel. It is used as
a resource when investigating kernel problems. Issue the
following command to install the map file:
cp -iv System.map /boot/System.map-4.15.3
The kernel configuration file .config
produced by the make menuconfig step above
contains all the configuration selections for the kernel that
was just compiled. It is a good idea to keep this file for
future reference:
cp -iv .config /boot/config-4.15.3
Install the documentation for the Linux kernel:
install -d /usr/share/doc/linux-4.15.3 cp -r Documentation/* /usr/share/doc/linux-4.15.3
It is important to note that the files in the kernel source directory are not owned by root. Whenever a package is unpacked as user root (like we did inside chroot), the files have the user and group IDs of whatever they were on the packager's computer. This is usually not a problem for any other package to be installed because the source tree is removed after the installation. However, the Linux source tree is often retained for a long time. Because of this, there is a chance that whatever user ID the packager used will be assigned to somebody on the machine. That person would then have write access to the kernel source.
In many cases, the configuration of the kernel will need to be updated for packages that will be installed later in BLFS. Unlike other packages, it is not necessary to remove the kernel source tree after the newly built kernel is installed.
If the kernel source tree is going to be retained, run
chown -R 0:0
on the linux-4.15.3
directory
to ensure all files are owned by user root.
Some kernel documentation recommends creating a symlink
from /usr/src/linux
pointing
to the kernel source directory. This is specific to kernels
prior to the 2.6 series and must
not be created on an LFS system as it can cause
problems for packages you may wish to build once your base
LFS system is complete.
The headers in the system's include
directory (/usr/include
) should always be the ones against which
Glibc was compiled, that is, the sanitised headers
installed in Section 6.7,
“Linux-4.15.3 API Headers”. Therefore, they
should never be
replaced by either the raw kernel headers or any other
kernel sanitized headers.
Most of the time Linux modules are loaded automatically, but
sometimes it needs some specific direction. The program that
loads modules, modprobe or insmod, uses /etc/modprobe.d/usb.conf
for this purpose.
This file needs to be created so that if the USB drivers
(ehci_hcd, ohci_hcd and uhci_hcd) have been built as modules,
they will be loaded in the correct order; ehci_hcd needs to
be loaded prior to ohci_hcd and uhci_hcd in order to avoid a
warning being output at boot time.
Create a new file /etc/modprobe.d/usb.conf
by running the
following:
install -v -m755 -d /etc/modprobe.d
cat > /etc/modprobe.d/usb.conf << "EOF"
# Begin /etc/modprobe.d/usb.conf
install ohci_hcd /sbin/modprobe ehci_hcd ; /sbin/modprobe -i ohci_hcd ; true
install uhci_hcd /sbin/modprobe ehci_hcd ; /sbin/modprobe -i uhci_hcd ; true
# End /etc/modprobe.d/usb.conf
EOF
|
Contains all the configuration selections for the kernel |
|
|
The engine of the Linux system. When turning on the computer, the kernel is the first part of the operating system that gets loaded. It detects and initializes all components of the computer's hardware, then makes these components available as a tree of files to the software and turns a single CPU into a multitasking machine capable of running scores of programs seemingly at the same time |
|
|
A list of addresses and symbols; it maps the entry points and addresses of all the functions and data structures in the kernel |
Configuring GRUB incorrectly can render your system inoperable without an alternate boot device such as a CD-ROM. This section is not required to boot your LFS system. You may just want to modify your current boot loader, e.g. Grub-Legacy, GRUB2, or LILO.
Ensure that an emergency boot disk is ready to “rescue” the computer if the
computer becomes unusable (un-bootable). If you do not
already have a boot device, you can create one. In order for
the procedure below to work, you need to jump ahead to BLFS
and install xorriso
from the
libisoburn package.
cd /tmp grub-mkrescue --output=grub-img.iso xorriso -as cdrecord -v dev=/dev/cdrw blank=as_needed grub-img.iso
To boot LFS on host systems that have UEFI enabled, the kernel needs to have been built with the CONFIG_EFI_STUB capabality described in the previous section. However, LFS can be booted using GRUB2 without such an addition. To do this, the UEFI Mode and Secure Boot capabilities in the host system's BIOS need to be turned off. For details, see the lfs-uefi.txt hint at http://www.linuxfromscratch.org/hints/downloads/files/lfs-uefi.txt.
GRUB uses its own naming structure for drives and partitions
in the form of (hdn,m), where n is the hard drive number and
m is the partition
number. The hard drive number starts from zero, but the
partition number starts from one for normal partitions and
five for extended partitions. Note that this is different
from earlier versions where both numbers started from zero.
For example, partition sda1
is
(hd0,1) to GRUB and
sdb3
is (hd1,3). In contrast to Linux,
GRUB does not consider CD-ROM drives to be hard drives. For
example, if using a CD on hdb
and a second hard drive on hdc
,
that second hard drive would still be (hd1).
GRUB works by writing data to the first physical track of the hard disk. This area is not part of any file system. The programs there access GRUB modules in the boot partition. The default location is /boot/grub/.
The location of the boot partition is a choice of the user
that affects the configuration. One recommendation is to have
a separate small (suggested size is 100 MB) partition just
for boot information. That way each build, whether LFS or
some commercial distro, can access the same boot files and
access can be made from any booted system. If you choose to
do this, you will need to mount the separate partition, move
all files in the current /boot
directory (e.g. the linux kernel you just built in the
previous section) to the new partition. You will then need to
unmount the partition and remount it as /boot
. If you do this, be sure to update
/etc/fstab
.
Using the current lfs partition will also work, but configuration for multiple systems is more difficult.
Using the above information, determine the appropriate
designator for the root partition (or boot partition, if a
separate one is used). For the following example, it is
assumed that the root (or separate boot) partition is
sda2
.
Install the GRUB files into /boot/grub
and set up the boot track:
The following command will overwrite the current boot loader. Do not run the command if this is not desired, for example, if using a third party boot manager to manage the Master Boot Record (MBR).
grub-install /dev/sda
Generate /boot/grub/grub.cfg
:
cat > /boot/grub/grub.cfg << "EOF"
# Begin /boot/grub/grub.cfg
set default=0
set timeout=5
insmod ext2
set root=(hd0,2)
menuentry "GNU/Linux, Linux 4.15.3-lfs-8.2" {
linux /boot/vmlinuz-4.15.3-lfs-8.2 root=/dev/sda2 ro
}
EOF
From GRUB's perspective, the kernel files are relative to the partition used. If you used a separate /boot partition, remove /boot from the above linux line. You will also need to change the set root line to point to the boot partition.
GRUB is an extremely powerful program and it provides a tremendous number of options for booting from a wide variety of devices, operating systems, and partition types. There are also many options for customization such as graphical splash screens, playing sounds, mouse input, etc. The details of these options are beyond the scope of this introduction.
There is a command, grub-mkconfig, that can write a configuration file automatically. It uses a set of scripts in /etc/grub.d/ and will destroy any customizations that you make. These scripts are designed primarily for non-source distributions and are not recommended for LFS. If you install a commercial Linux distribution, there is a good chance that this program will be run. Be sure to back up your grub.cfg file.
Well done! The new LFS system is installed! We wish you much success with your shiny new custom-built Linux system.
It may be a good idea to create an /etc/lfs-release
file. By having this file,
it is very easy for you (and for us if you need to ask for help
at some point) to find out which LFS version is installed on
the system. Create this file by running:
echo 8.2 > /etc/lfs-release
It is also a good idea to create a file to show the status of your new system with respect to the Linux Standards Base (LSB). To create this file, run:
cat > /etc/lsb-release << "EOF" DISTRIB_ID="Linux From Scratch" DISTRIB_RELEASE="8.2" DISTRIB_CODENAME="<your name here>" DISTRIB_DESCRIPTION="Linux From Scratch" EOF
Be sure to put some sort of customization for the field 'DISTRIB_CODENAME' to make the system uniquely yours.
Now that you have finished the book, do you want to be counted as an LFS user? Head over to http://www.linuxfromscratch.org/cgi-bin/lfscounter.php and register as an LFS user by entering your name and the first LFS version you have used.
Let's reboot into LFS now.
Now that all of the software has been installed, it is time to reboot your computer. However, you should be aware of a few things. The system you have created in this book is quite minimal, and most likely will not have the functionality you would need to be able to continue forward. By installing a few extra packages from the BLFS book while still in our current chroot environment, you can leave yourself in a much better position to continue on once you reboot into your new LFS installation. Here are some suggestions:
A text mode browser such as Lynx will allow you to easily view the BLFS book in one virtual terminal, while building packages in another.

If you are in a situation where static IP configuration does not meet your networking requirements, installing a package such as dhcpcd or the client portion of dhcp may be useful.
Installing sudo may be useful for building packages as a non-root user and easily installing the resulting packages in your new system.
If you want to access your new system from a remote system within a comfortable GUI environment, install openssh and its prerequisite, openssl.
To make fetching files over the internet easier, install wget.
If one or more of your disk drives have a GUID partition table (GPT), either gptfdisk or parted will be useful.
Finally, a review of the following configuration files is also appropriate at this point.
/etc/bashrc
/etc/dircolors
/etc/fstab
/etc/hosts
/etc/inputrc
/etc/profile
/etc/resolv.conf
/etc/vimrc
/root/.bash_profile
/root/.bashrc
/etc/sysconfig/network
/etc/sysconfig/ifconfig.eth0
Now that we have said that, let's move on to booting our shiny new LFS installation for the first time! First exit from the chroot environment:
logout
Then unmount the virtual file systems:
umount -v $LFS/dev/pts umount -v $LFS/dev umount -v $LFS/run umount -v $LFS/proc umount -v $LFS/sys
Unmount the LFS file system itself:
umount -v $LFS
If multiple partitions were created, unmount the other partitions before unmounting the main one, like this:
umount -v $LFS/usr umount -v $LFS/home umount -v $LFS
Now, reboot the system with:
shutdown -r now
Assuming the GRUB boot loader was set up as outlined earlier, the menu is set to boot LFS 8.2 automatically.
When the reboot is complete, the LFS system is ready for use and more software may be added to suit your needs.
Thank you for reading this LFS book. We hope that you have found this book helpful and have learned more about the system creation process.
Now that the LFS system is installed, you may be wondering “What next?” To answer that question, we have compiled a list of resources for you.
Maintenance
Bugs and security notices are reported regularly for all software. Since an LFS system is compiled from source, it is up to you to keep abreast of such reports. There are several online resources that track such reports, some of which are shown below:
CERT (Computer Emergency Response Team)
CERT has a mailing list that publishes security alerts concerning various operating systems and applications. Subscription information is available at http://www.us-cert.gov/cas/signup.html.
Bugtraq
Bugtraq is a full-disclosure computer security mailing list. It publishes newly discovered security issues, and occasionally potential fixes for them. Subscription information is available at http://www.securityfocus.com/archive.
Beyond Linux From Scratch
The Beyond Linux From Scratch book covers installation procedures for a wide range of software beyond the scope of the LFS Book. The BLFS project is located at http://www.linuxfromscratch.org/blfs/.
LFS Hints
The LFS Hints are a collection of educational documents submitted by volunteers in the LFS community. The hints are available at http://www.linuxfromscratch.org/hints/list.html.
Mailing lists
There are several LFS mailing lists you may subscribe to if you are in need of help, want to stay current with the latest developments, want to contribute to the project, and more. See Chapter 1 - Mailing Lists for more information.
The Linux Documentation Project
The goal of The Linux Documentation Project (TLDP) is to collaborate on all of the issues of Linux documentation. The TLDP features a large collection of HOWTOs, guides, and man pages. It is located at http://www.tldp.org/.
|
ABI |
Application Binary Interface |
|
ALFS |
Automated Linux From Scratch |
|
API |
Application Programming Interface |
|
ASCII |
American Standard Code for Information Interchange |
|
BIOS |
Basic Input/Output System |
|
BLFS |
Beyond Linux From Scratch |
|
BSD |
Berkeley Software Distribution |
|
chroot |
change root |
|
CMOS |
Complementary Metal Oxide Semiconductor |
|
COS |
Class Of Service |
|
CPU |
Central Processing Unit |
|
CRC |
Cyclic Redundancy Check |
|
CVS |
Concurrent Versions System |
|
DHCP |
Dynamic Host Configuration Protocol |
|
DNS |
Domain Name Service |
|
EGA |
Enhanced Graphics Adapter |
|
ELF |
Executable and Linkable Format |
|
EOF |
End of File |
|
EQN |
equation |
|
ext2 |
second extended file system |
|
ext3 |
third extended file system |
|
ext4 |
fourth extended file system |
|
FAQ |
Frequently Asked Questions |
|
FHS |
Filesystem Hierarchy Standard |
|
FIFO |
First-In, First Out |
|
FQDN |
Fully Qualified Domain Name |
|
FTP |
File Transfer Protocol |
|
GB |
Gigabytes |
|
GCC |
GNU Compiler Collection |
|
GID |
Group Identifier |
|
GMT |
Greenwich Mean Time |
|
HTML |
Hypertext Markup Language |
|
IDE |
Integrated Drive Electronics |
|
IEEE |
Institute of Electrical and Electronic Engineers |
|
IO |
Input/Output |
|
IP |
Internet Protocol |
|
IPC |
Inter-Process Communication |
|
IRC |
Internet Relay Chat |
|
ISO |
International Organization for Standardization |
|
ISP |
Internet Service Provider |
|
KB |
Kilobytes |
|
LED |
Light Emitting Diode |
|
LFS |
Linux From Scratch |
|
LSB |
Linux Standard Base |
|
MB |
Megabytes |
|
MBR |
Master Boot Record |
|
MD5 |
Message Digest 5 |
|
NIC |
Network Interface Card |
|
NLS |
Native Language Support |
|
NNTP |
Network News Transport Protocol |
|
NPTL |
Native POSIX Threading Library |
|
OSS |
Open Sound System |
|
PCH |
Pre-Compiled Headers |
|
PCRE |
Perl Compatible Regular Expression |
|
PID |
Process Identifier |
|
PTY |
pseudo terminal |
|
QOS |
Quality Of Service |
|
RAM |
Random Access Memory |
|
RPC |
Remote Procedure Call |
|
RTC |
Real Time Clock |
|
SBU |
Standard Build Unit |
|
SCO |
The Santa Cruz Operation |
|
SHA1 |
Secure-Hash Algorithm 1 |
|
TLDP |
The Linux Documentation Project |
|
TFTP |
Trivial File Transfer Protocol |
|
TLS |
Thread-Local Storage |
|
UID |
User Identifier |
|
umask |
user file-creation mask |
|
USB |
Universal Serial Bus |
|
UTC |
Coordinated Universal Time |
|
UUID |
Universally Unique Identifier |
|
VC |
Virtual Console |
|
VGA |
Video Graphics Array |
|
VT |
Virtual Terminal |
We would like to thank the following people and organizations for their contributions to the Linux From Scratch Project.
Gerard Beekmans <gerard AT linuxfromscratch D0T org> – LFS Creator
Bruce Dubbs <bdubbs AT linuxfromscratch D0T org> – LFS Managing Editor
Jim Gifford <jim AT linuxfromscratch D0T org> – CLFS Project Co-Leader
Pierre Labastie <pierre AT linuxfromscratch D0T org> – BLFS Editor and ALFS Lead
DJ Lucas <dj AT linuxfromscratch D0T org> – LFS and BLFS Editor
Ken Moffat <ken AT linuxfromscratch D0T org> – BLFS Editor
Countless other people on the various LFS and BLFS mailing lists who helped make this book possible by giving their suggestions, testing the book, and submitting bug reports, instructions, and their experiences with installing various packages.
Manuel Canales Esparcia <macana AT macana-es D0T com> – Spanish LFS translation project
Johan Lenglet <johan AT linuxfromscratch D0T org> – French LFS translation project until 2008
Jean-Philippe Mengual <jmengual AT linuxfromscratch D0T org> – French LFS translation project 2008-2016
Julien Lepiller <jlepiller AT linuxfromscratch D0T org> – French LFS translation project 2017-present
Anderson Lizardo <lizardo AT linuxfromscratch D0T org> – Portuguese LFS translation project
Thomas Reitelbach <tr AT erdfunkstelle D0T de> – German LFS translation project
Scott Kveton <scott AT osuosl D0T org> – lfs.oregonstate.edu mirror
William Astle <lost AT l-w D0T net> – ca.linuxfromscratch.org mirror
Eujon Sellers<EMAIL_ADDRESS>– lfs.introspeed.com mirror
Justin Knierim<EMAIL_ADDRESS>– lfs-matrix.net mirror
Manuel Canales Esparcia <manuel AT linuxfromscratch D0T org> – lfsmirror.lfs-es.info mirror
Luis Falcon <Luis Falcon> – torredehanoi.org mirror
Guido Passet <guido AT primerelay D0T net> – nl.linuxfromscratch.org mirror
Bastiaan Jacques <baafie AT planet D0T nl> – lfs.pagefault.net mirror
Sven Cranshoff <sven D0T cranshoff AT lineo D0T be> – lfs.lineo.be mirror
Scarlet Belgium – lfs.scarlet.be mirror
Sebastian Faulborn <info AT aliensoft D0T org> – lfs.aliensoft.org mirror
Stuart Fox <stuart AT dontuse D0T ms> – lfs.dontuse.ms mirror
Ralf Uhlemann <admin AT realhost D0T de> – lfs.oss-mirror.org mirror
Antonin Sprinzl <Antonin D0T Sprinzl AT tuwien D0T ac D0T at> – at.linuxfromscratch.org mirror
Fredrik Danerklint <fredan-lfs AT fredan D0T org> – se.linuxfromscratch.org mirror
Franck <franck AT linuxpourtous D0T com> – lfs.linuxpourtous.com mirror
Philippe Baque <baque AT cict D0T fr> – lfs.cict.fr mirror
Vitaly Chekasin <gyouja AT pilgrims D0T ru> – lfs.pilgrims.ru mirror
Benjamin Heil <kontakt AT wankoo D0T org> – lfs.wankoo.org mirror
Satit Phermsawang <satit AT wbac D0T ac D0T th> – lfs.phayoune.org mirror
Shizunet Co.,Ltd. <info AT shizu-net D0T jp> – lfs.mirror.shizu-net.jp mirror
Init World <http://www.initworld.com/> – lfs.initworld.com mirror
Jason Andrade <jason AT dstc D0T edu D0T au> – au.linuxfromscratch.org mirror
Christine Barczak <theladyskye AT linuxfromscratch D0T org> – LFS Book Editor
Archaic<EMAIL_ADDRESS>– LFS Technical Writer/Editor, HLFS Project Leader, BLFS Editor, Hints and Patches Project Maintainer
Matthew Burgess <matthew AT linuxfromscratch D0T org> – LFS Project Leader, LFS Technical Writer/Editor
Nathan Coulson <nathan AT linuxfromscratch D0T org> – LFS-Bootscripts Maintainer
Timothy Bauscher
Robert Briggs
Ian Chilton
Jeroen Coumans <jeroen AT linuxfromscratch D0T org> – Website Developer, FAQ Maintainer
Manuel Canales Esparcia <manuel AT linuxfromscratch D0T org> – LFS/BLFS/HLFS XML and XSL Maintainer
Alex Groenewoud – LFS Technical Writer
Marc Heerdink
Jeremy Huntwork <jhuntwork AT linuxfromscratch D0T org> – LFS Technical Writer, LFS LiveCD Maintainer
Bryan Kadzban <bryan AT linuxfromscratch D0T org> – LFS Technical Writer
Mark Hymers
Seth W. Klein – FAQ maintainer
Nicholas Leippe <nicholas AT linuxfromscratch D0T org> – Wiki Maintainer
Anderson Lizardo <lizardo AT linuxfromscratch D0T org> – Website Backend-Scripts Maintainer
Randy McMurchy <randy AT linuxfromscratch D0T org> – BLFS Project Leader, LFS Editor
Dan Nicholson <dnicholson AT linuxfromscratch D0T org> – LFS and BLFS Editor
Alexander E. Patrakov <alexander AT linuxfromscratch D0T org> – LFS Technical Writer, LFS Internationalization Editor, LFS Live CD Maintainer
Simon Perreault
Scot Mc Pherson <scot AT linuxfromscratch D0T org> – LFS NNTP Gateway Maintainer
Douglas R. Reno <renodr AT linuxfromscratch D0T org> – Systemd Editor
Ryan Oliver <ryan AT linuxfromscratch D0T org> – CLFS Project Co-Leader
Greg Schafer <gschafer AT zip D0T com D0T au> – LFS Technical Writer and Architect of the Next Generation 64-bit-enabling Build Method
Jesse Tie-Ten-Quee – LFS Technical Writer
James Robertson <jwrober AT linuxfromscratch D0T org> – Bugzilla Maintainer
Tushar Teredesai <tushar AT linuxfromscratch D0T org> – BLFS Book Editor, Hints and Patches Project Leader
Jeremy Utley <jeremy AT linuxfromscratch D0T org> – LFS Technical Writer, Bugzilla Maintainer, LFS-Bootscripts Maintainer
Zack Winkles <zwinkles AT gmail D0T com> – LFS Technical Writer
Every package built in LFS relies on one or more other packages in order to build and install properly. Some packages even participate in circular dependencies, that is, the first package depends on the second which in turn depends on the first. Because of these dependencies, the order in which packages are built in LFS is very important. The purpose of this page is to document the dependencies of each package built in LFS.
For each package we build, we have listed three, and sometimes four, types of dependencies. The first lists what other packages need to be available in order to compile and install the package in question. The second lists what packages, in addition to those on the first list, need to be available in order to run the test suites. The third list of dependencies are packages that require this package to be built and installed in its final location before they are built and installed. In most cases, this is because these packages will hard code paths to binaries within their scripts. If not built in a certain order, this could result in paths of /tools/bin/[binary] being placed inside scripts installed to the final system. This is obviously not desirable.
The last list of dependencies are optional packages that are not addressed in LFS, but could be useful to the user. These packages may have additional mandatory or optional dependencies of their own. For these dependencies, the recommended practice is to install them after completion of the LFS book and then go back and rebuild the LFS package. In several cases, re-installation is addressed in BLFS.
The scripts in this appendix are listed by the directory where
they normally reside. The order is /etc/rc.d/init.d
, /etc/sysconfig
, /etc/sysconfig/network-devices
, and
/etc/sysconfig/network-devices/services
.
Within each section, the files are listed in the order they are
normally called.
The rc
script is the first
script called by init and
initiates the boot process.
#!/bin/bash ######################################################################## # Begin rc # # Description : Main Run Level Control Script # # Authors : Gerard Beekmans - gerard AT linuxfromscratch D0T org # : DJ Lucas - dj AT linuxfromscratch D0T org # Update : Bruce Dubbs - bdubbs AT linuxfromscratch D0T org # # Version : LFS 7.0 # ######################################################################## . /lib/lsb/init-functions print_error_msg() { log_failure_msg # $i is set when called MSG="FAILURE:\n\nYou should not be reading this error message.\n\n" MSG="${MSG}It means that an unforeseen error took place in\n" MSG="${MSG}${i},\n" MSG="${MSG}which exited with a return value of ${error_value}.\n" MSG="${MSG}If you're able to track this error down to a bug in one of\n" MSG="${MSG}the files provided by the ${DISTRO_MINI} book,\n" MSG="${MSG}please be so kind to inform us at ${DISTRO_CONTACT}.\n" log_failure_msg "${MSG}" log_info_msg "Press Enter to continue..." wait_for_user } check_script_status() { # $i is set when called if [ ! -f ${i} ]; then log_warning_msg "${i} is not a valid symlink." SCRIPT_STAT="1" fi if [ ! -x ${i} ]; then log_warning_msg "${i} is not executable, skipping." SCRIPT_STAT="1" fi } run() { if [ -z $interactive ]; then ${1} ${2} return $? fi while true; do read -p "Run ${1} ${2} (Yes/no/continue)? " -n 1 runit echo case ${runit} in c | C) interactive="" ${i} ${2} ret=${?} break; ;; n | N) return 0 ;; y | Y) ${i} ${2} ret=${?} break ;; esac done return $ret } # Read any local settings/overrides [ -r /etc/sysconfig/rc.site ] && source /etc/sysconfig/rc.site DISTRO=${DISTRO:-"Linux From Scratch"}<EMAIL_ADDRESS>(Registration required)"} DISTRO_MINI=${DISTRO_MINI:-"LFS"} IPROMPT=${IPROMPT:-"no"} # These 3 signals will not cause our script to exit trap "" INT QUIT TSTP [ "${1}" != "" ] && runlevel=${1} if [ "${runlevel}" == "" ]; then echo "Usage: ${0} <runlevel>" >&2 exit 1 fi previous=${PREVLEVEL} [ "${previous}" == "" ] && previous=N if [ ! -d /etc/rc.d/rc${runlevel}.d ]; then log_info_msg "/etc/rc.d/rc${runlevel}.d does not exist.\n" exit 1 fi if [ "$runlevel" == "6" -o "$runlevel" == "0" ]; then IPROMPT="no"; fi # Note: In ${LOGLEVEL:-7}, it is ':' 'dash' '7', not minus 7 if [ "$runlevel" == "S" ]; then [ -r /etc/sysconfig/console ] && source /etc/sysconfig/console dmesg -n "${LOGLEVEL:-7}" fi if [ "${IPROMPT}" == "yes" -a "${runlevel}" == "S" ]; then # The total length of the distro welcome string, without escape codes wlen=${wlen:-$(echo "Welcome to ${DISTRO}" | wc -c )} welcome_message=${welcome_message:-"Welcome to ${INFO}${DISTRO}${NORMAL}"} # The total length of the interactive string, without escape codes ilen=${ilen:-$(echo "Press 'I' to enter interactive startup" | wc -c )} i_message=${i_message:-"Press '${FAILURE}I${NORMAL}' to enter interactive startup"} # dcol and icol are spaces before the message to center the message # on screen. itime is the amount of wait time for the user to press a key wcol=$(( ( ${COLUMNS} - ${wlen} ) / 2 )) icol=$(( ( ${COLUMNS} - ${ilen} ) / 2 )) itime=${itime:-"3"} echo -e "\n\n" echo -e "\\033[${wcol}G${welcome_message}" echo -e "\\033[${icol}G${i_message}${NORMAL}" echo "" read -t "${itime}" -n 1 interactive 2>&1 > /dev/null fi # Make lower case [ "${interactive}" == "I" ] && interactive="i" [ "${interactive}" != "i" ] && interactive="" # Read the state file if it exists from runlevel S [ -r /var/run/interactive ] && source /var/run/interactive # Attempt to stop all services started by the previous runlevel, # and killed in this runlevel if [ "${previous}" != "N" ]; then for i in $(ls -v /etc/rc.d/rc${runlevel}.d/K* 2> /dev/null) do check_script_status if [ "${SCRIPT_STAT}" == "1" ]; then SCRIPT_STAT="0" continue fi suffix=${i#/etc/rc.d/rc$runlevel.d/K[0-9][0-9]} prev_start=/etc/rc.d/rc$previous.d/S[0-9][0-9]$suffix sysinit_start=/etc/rc.d/rcS.d/S[0-9][0-9]$suffix if [ "${runlevel}" != "0" -a "${runlevel}" != "6" ]; then if [ ! -f ${prev_start} -a ! -f ${sysinit_start} ]; then MSG="WARNING:\n\n${i} can't be " MSG="${MSG}executed because it was not " MSG="${MSG}not started in the previous " MSG="${MSG}runlevel (${previous})." log_warning_msg "$MSG" continue fi fi run ${i} stop error_value=${?} if [ "${error_value}" != "0" ]; then print_error_msg; fi done fi if [ "${previous}" == "N" ]; then export IN_BOOT=1; fi if [ "$runlevel" == "6" -a -n "${FASTBOOT}" ]; then touch /fastboot fi # Start all functions in this runlevel for i in $( ls -v /etc/rc.d/rc${runlevel}.d/S* 2> /dev/null) do if [ "${previous}" != "N" ]; then suffix=${i#/etc/rc.d/rc$runlevel.d/S[0-9][0-9]} stop=/etc/rc.d/rc$runlevel.d/K[0-9][0-9]$suffix prev_start=/etc/rc.d/rc$previous.d/S[0-9][0-9]$suffix [ -f ${prev_start} -a ! -f ${stop} ] && continue fi check_script_status if [ "${SCRIPT_STAT}" == "1" ]; then SCRIPT_STAT="0" continue fi case ${runlevel} in 0|6) run ${i} stop ;; *) run ${i} start ;; esac error_value=${?} if [ "${error_value}" != "0" ]; then print_error_msg; fi done # Store interactive variable on switch from runlevel S and remove if not if [ "${runlevel}" == "S" -a "${interactive}" == "i" ]; then echo "interactive=\"i\"" > /var/run/interactive else rm -f /var/run/interactive 2> /dev/null fi # Copy the boot log on initial boot only if [ "${previous}" == "N" -a "${runlevel}" != "S" ]; then cat $BOOTLOG >> /var/log/boot.log # Mark the end of boot echo "--------" >> /var/log/boot.log # Remove the temporary file rm -f $BOOTLOG 2> /dev/null fi # End rc