Customized Linux System

Introduction

Research on LFS (Linux from scratch)
For a while, I found that some problems, such as tutorials on the official website and analysis articles by some third parties, have one thing in common. The details are too detailed. Too practical and too theoretical have the same disadvantages-it is unfavorable to improve learning efficiency [note]. In addition, the tutorials in the [lower-level] style give people a feeling of being transparent. For example, you have made things, but you may not be able to understand it in a few steps, but just do it blindly.

So far, I have seen that the official tutorial does not provide sufficient background information. Therefore, it is not intended for general Linux users, including application developers in Linux. It is intended for system developers. If customized Linux has objective and true values, and OS customization is an arduous task, a large amount of third-party supplementary information such as this is required. This article only summarizes the learning experience, I will add some [metaphysical] information to the LFS tutorial to make up for the lack of the [Top-Down] approach in the Learning market.

Note: Because efficiency is the ratio of efficacy to time, the efficacy itself is difficult to accurately measure, and efficiency becomes unpredictable and can be guessed at will.

Top-down and bottom-up

Is it highly efficient to learn and study a new thing in a bottom-up sequence, or vice versa? [Top-Down] refers to learning abstract content first, while [bottom-up] refers to learning specific details first. I personally have always used a top-down approach. I don't know if Chinese people love specific things for cultural reasons. Many domestic tutorials and articles are based on a bottom-up approach. There are obvious advantages from the bottom up and [less obvious] disadvantages. The advantage is that it is operable and easy to use. The disadvantage is that the [overall efficiency] of learning is not as good as that of top-down. Because the specific things are generally applied to a special field, there are many special things, and under the premise of [same level of description], relative to the specific details, the general content [closer to us] can be seen by the cognitive rules. The general content is easier for our brain to absorb it.

Customized Linux?

Customized Linux? This goal is interesting and even excited to anyone familiar with Linux. But what is actually? Is everyone really capable of customizing an OS? If only a small number of hackers and computer enthusiasts have this capability, the OS will be as complicated as a flood of beasts for most others. Is this a fantasy? I think so. The intention of LFS is friendly, the purpose is correct, and the meaning is also meaningful, but the method is a bit unrealistic; using tutorials to guide a common Linux User to customize their own Linux system is similar to a fantasy. The learning curve is steep because it is too difficult. I think that some people think that Linux customization may be because they have "played" Linux. If they change to a custom CPU, they do not think it is possible or necessary. Apart from the physical form, must the CPU and OS be less complex than the CPU? I disagree.

Why do we need customization?

From the perspective of learning, it is to thoroughly understand the Linux system (internal structure) and train the ability to fully control the Linux system. Including building a system module from the source code and controlling the volume and security of the system.

From the perspective of production, there are various reasons for the need for customized Linux systems, such as system performance, such as embedded systems.

What is customized?

The LFS author said that the project was initiated to customize the startup script style. Obviously, this customization task is too small and not practical. Practical customization is of course customized for embedded systems. Customization goals vary, and customization varies depending on the situation. However, there is a default assumption that the custom system is a complete and available system.

So what are the necessary tools (software packages) Besides the kernel for a complete and available Linux system?

A complete and available system does not only mean a kernel, boot programs, login programs, assembler programs, compilation programs, script interpreters, debugging programs, text editing programs, and email programs may also be required. If the definition of the [available system] is cross-cutting, the required software package may also have multiple combinations. For example, the release of a desktop application can be used as either a web server or a development workstation. The former does not need to compile the program, and the latter does. Obviously, the integrity of the "Complete Available Linux system" depends on your [system's purpose], that is, it is used to install embedded devices, as Web servers, and as database servers, or used as a desktop application.

System Customization

Again, is there a [non-kernel] General Software Package [all applications] required? The answer is yes. Some software packages are indeed necessary for available systems, such as Bootloader and glibc. However, some software packages are optional for different purposes. System applications can be roughly divided into three categories:

• Program Development (requires compiling and debugging programs and C static code libraries)
• System Management and Maintenance (including software and hardware installation and user management)
• Application computing (including network applications and desktop applications)

In addition, the software packages required by different users for the same application system are not the same. The following table lists various systems and the software packages required for them:

Package	Security Gateway	Web Server		Development Workstation		Desktop applications
		Web User	System User	Developer	System User	Desktop Users	System User
Bootloader (grub)	√	√	√	√	√	√	√
Kernel	√	√	√	√	√	√	√
Sysvinit	√	√	√	√	√	√	√
Util-Linux-ng (agetty)		√	√	√	√	√	√
......
Bash	√	√	√	√	√	√	√
Glibc	√	√	√	√	√	√	√
Coreutils	√	√	√	√	√	√	√
Linux API Headers				√			√
Binutils			√	√	√		√
Gcc			√	√	√		√
M4				√
Autoconf				√
Automake				√
Make			√		√		√
Tar			√		√		√
Gzip			√		√		√
Module-init-Tools					√		√
Udev					√		√
Inetutils					√		√
Man-pages					√		√
Man-DB					√		√
Squid	√
Netfilter	√
Apache		√
MySQL		√
PHP		√
X11				√		√
Vim				√		√
Figure note:	Core	Program Development	Software Installation System Management	System Maintenance System Management	Application computing

 

Software Package Customization

The above is system type customization, which is a coarse-grained customization; there is also fine-grained customization-customization of each [software package] on demand, that is, customization of the functions of the software package itself, for example, the LFS author customizes the kernel STARTUP script style to the kernel.

This may be due to the practical purpose of the project. The most lacking aspect of the original LFS tutorial is that dependencies between software packages, code libraries, data files, and hardware are not explained in detail. This article attempts to illustrate the functional roles and dependencies of each software package with the following points:

1. Purpose:
2. Dependency: the correlation between the software and hardware systems, and assumptions about the operating environment of the software package
3. Support: provide services to the previous software package to build its dependent environment, for example, pass the [runtime configuration information ];
4. Configuration: function configuration of the software package -- [configuration information during build]
5. Installation location: Most programs are installed in the file system, and the boot program is installed in the boot sector.

Grub

• Purpose: To take over the firmware (such as BIOS) for further system initialization and possibly user interaction, and load the specified kernel image.
• Dependency: bootloader is a software package highly related to hardware and runs on a bare processor. Grub is related to the x86 processor system and may use the original driver provided by the BIOS to access basic devices, such as accessing the IDE hard disk. By default, LFS assumes that a dedicated x86linux system is built on the general release version running on x86 machines, so grub is commonly used.
• Supported: create an environment for the kernel execution. In addition, based on the interaction with the user or the previous configuration (/boot/GRUB/menu. LST) transmits the execution parameters (dynamic configuration parameters) required by the kernel, such as the device where the root file system is located, init, etc.
• Configuration:
  • Static configuration during compilation
  • Dynamic configuration during running:/boot/GRUB/menu. lst
• Installation path: Boot Sector. install other auxiliary programs in/boot/grub.

Linux Kernel

• Purpose: To take over bootloader for more advanced system initialization, build a virtual machine, enable multi-process and virtual memory, and finally execute the dynamic configuration item init specified program, or execute the default INIT program in sequence: /bin/init |/sbin/init |/usr/bin/init |/bin/sh.
• Dependency: the kernel has system-related initialization, So it depends on the x86 processor system. In addition, kernel relies on bootloader to provide some dynamic configuration parameters.
• Support: Create an environment for multi-user multi-process execution and execute the first user process init
• Configuration
  • Static configuration during compilation:-arch = x86
  • Dynamic configuration during running: Only command lines, such as root | Console
    
    
    | Init ...... For more details, see the kerneldocument --kernel-parameters.txt.
• Installation path:/boot

Sysvinit

• Function purpose: the INIT program is the agreed exit of the kernel boot. It can be guessed from the name that init is still initializing the system. However, the initialized system is more logical and advanced, programmers who have a certain understanding of init know the concept of running level-runlevel. A running level represents a system and has its own configuration status, which needs to be initialized. When the running level is 3, run/etc/rc. d/RC. sysinit and/etc/rc. d/RC 3 script program, for more information here (http://www.comptechdoc.org/ OS /linux/startupman/linux_suinit.html
  ). In addition, init is the real support controller of the system, because after init is executed, it is responsible for controlling the operation of the entire system, such as user login and logout, cleaning and shutdown of dead processes, etc, the kernel is only responsible for processing system calls. The user program processes are [executed] Through system calls ]. Although init is a program running in the user space, its role is not general. First, it will not be killed by the user; second, it is the ancestor of all user processes.
• Dependency: in the second half of kernel initialization, the guiding code is no longer dependent on the hardware system; sysinit is certainly not dependent on the hardware system. However, as a user program, it depends on the C library of the system, which is called the dependency on the software system.
• Support: Execute the Getty program and provide the Getty command line parameters to prepare users to log on to the default terminal.
• Configuration:
  • Dynamic configuration during runtime:/etc/inittab ...... For more details, refer to [Linux System Administrator's Manual inittab (5 )]
• Installation path:/sbin
• Key components: init, halt, poweroff, reboot, runlevel, shutdown, sulogin, telinit

Util-Linux-ng (agetty)

• Function objective: Getty opens a tty port, prompts for a login name and invokes the/bin/LOGIN command. It is normally invoked by Init (8 ).
• Dependency: Depends on the C library of the system.
• Supported:
• Configuration:
  • Dynamic configuration during runtime:
• Installation path:/sbin
• Key components:/etc/issue, printed before the login prompt.

Bash

This package satisfies an LSB core requirement to provide a Bourne shell interface to the system. It was chosen over other shell packages because of its common usage and extensive capabilities beyond basic Shell functions.

Glibc

This package contains the main C library. Linux programs wocould not run without it.

Coreutils

This package contains a number of essential programs for viewing and manipulating files and directories.

Gcc

This package is the GNU Compiler Collection. It contains the C and C ++ compilers as well as several others not built by LFS.

Make

This package contains a program for directing the building of packages. It is required by almost every package in LFS.

Inux-libc-headers

Linux-libc-headers is a set of Linux kernel headers for building libc. since Linux 2.6, the kernel authors have frowned upon userspace programs including the kernel headers directly. instead, the recommendation was to use sanitized kernel headers for userspace programs. the Linux libc headers project provides such a set of sanitized headers. it was initiated as a PLD Linux specific project.

How to customize it?

The customization process is defined based on the customization start point and the customization end point. The starting point of customization here is an available Linux development workstation, but the installed Release Version can also be live-CD; the end point is also available, but fully customized Linux development workstation.

The basic customization method is to build a custom Linux system on the available Linux development workstation. The LFS system will be built by using an already installed Linux distribution (such as Debian, mandriva, Red Hat, orsuse ).

General process:

1. Create a new local partition to compile and install the new LFS system. Create a New Linux native partition and file system. This is the place where the new LFS system will be compiled and installed.
2. Download the required software packages and patches to a specific place. packages and patches need to be downloaded to build an LFS system and how to store them on the new file system.
3. Set up an appropriate working environment setup an appropriate working environment.
4. Build a temporary compilation tool chain independent of development machines, installation of a number of packages that will form the basic development suite (or toolchain) which is used to build the actual system
   1. Build a first pass of the toolchain, including binutils and GCC (first pass basically means these two core packages will be reinstalled ).
   2. The next step is to build glibc, the C library. glibc will be compiled by the toolchain programs built in the first pass.
   3. Then, a second pass of the toolchain will be built. This time, the toolchain will be dynamically linked against the newly built glibc.
   4. The remaining chapter 5 packages are built using this second pass toolchain. When this is done, the LFS installation process will no longer depend on the host distribution, with the exception of the running kernel.
5. Use the new development tool chain to compile other LSF software packages
   • Build a first pass of the toolchain, including binutils and GCC (first pass basically means these two core packages will be reinstalled ). the next step is to build glibc, the C library. glibc will be compiled by the toolchain programs built in the first pass. then, a second pass of the toolchain will be built. this time, the toolchain will be dynamically linked against the newly built glibc. the remaining chapter 5 packages are
     Built using this second pass toolchain. When this is done, the LFS installation process will no longer depend on the host distribution, with the exception of the running kernel.
6. Full LFS system is built.
   • Chroot (Change root) program is used to enter a virtual environment and start a new shell whose root directory will be set to the LFS partition.
7. Set up the LFS-bootscripts
8. The kernel and boot loader are set up