Construct a graphical installation program for Linux (1)

This section describes how to customize the system installation environment, including kernel generation and installation, initial ramdisk generation, and minimal customization of the installation environment.
Since Caldera launched the first graphical installation program for Linux system, most mainstream Linux installations currently use graphical installation programs for system environment installation, such as RedHat installation program anaconda, suse installer yast2, Caldera installer lizard, and Mandrake installer gi.
The installation programs of these mainstream vendors share a common feature, that is, they first construct a complete and minimal Linux runtime environment and customize the Linux Startup Process so that after the system kernel is started, load a system loader, which loads part or all of the customized Linux runtime environment into the memory, and then transfers the control to the graphical installer. Finally, set the corresponding language environment and start the corresponding system installation process.
1 Introduction to mainstream installation programs
The installation program lizard of Caldera is the first graphical installation program in the Linux World. All its programs are compiled in c ++. The graphical style is based on kde and qt. It is worth mentioning that caldera modified the kernel during custom graphical installation to enable graphical startup of the kernel. At the same time, its installation program has powerful hardware detection functions, some non-plug-and-play isa devices can be detected, and a help system similar to the html style is also provided. Because the installer requires a refined environment, and the general XWindows Window Manager cannot meet the requirement too much and occupies too many resources), caldera also provides a minimal window manager lwm. During the installation of the system package in caldera, you can also play the beans game, which is also a major idea of lizard.
The Redhat installer anaconda may be one of the most familiar installers. All of its programs are completed by Python. Python is an object-oriented scripting language. You can obtain relevant information at http: // www.python.org. Redhat uses Python Gtk as a graphical interface development tool. After you unbind the source code package of anaconda, you will find an anaconda file, which is the main file for program execution. It provides a minimal slang library to support text installation. The biggest feature of the Redhat installer is that it is very stable and supports many drivers. Strong hardware support indicates that the Redhat kernel is well customized, and has received support from a considerable number of vendors ). However, the Redhat installer is not particularly powerful. For example, reiserfs and lvm are not supported and Chinese version 7.2 may be released ). There are also many manufacturers' installation programs that slightly modify the RedHat source code, such as VALinux and zhongke Hongqi.
For the installation program gi of Mandrake, all its programs are compiled using Perl. You can download the latest installation program from the CVS server of Mandrake. Perl is a powerful scripting language that can easily process various configuration scripts on Linux. Its graphical interface is compiled using Perl-GTK. The installation program of Mandrake is the first mainstream release that provides Chinese installation. Its installer features new features and supports many features, including complex file systems, wireless communication devices, and various printer support.
Redhat and Mandrake installation programs are composed of scripts. Although they are relatively slow, the installation programs are generally stable and easy to transplant to other platforms. The entire installation environment of Redhat is saved in a stage2.img file. You can run the following command:
Mount-o loop stage2.img/mnt/tmp
Upload it to the specified directory to view the Redhat installer structure. The installation environment of Mandrake is stored in the mdkinst directory.
2. Composition of the installation environment
A graphical installation environment is actually a minimal Linux operating environment. It is generally composed of the following parts: Linux kernel installation, Linux initial Ram disk, system required for running shell commands and programs, system library, initialization program, external commands required during system running, XFree86 subsystem, font set and localized environment settings, system desktop style and textures, keyboard ing, device configuration database, system installation program, and so on.
The system kernel vmlinuz exists in the boot image of the system. When the system is started, it is transferred to Linux and then to the initial Ram disk. Then, programs on the Ram disk are loaded to run the first-stage loader of the installer. This is an executable program. It generally loads the hard drive module, transfers the entire installation environment on the disk to the memory, and mounts it as the root partition.
At this time, there is a Linux system with minimal memory. After an image program stops running, the memory occupied by it is released, and the control is transferred to the real system installer. At this time, the system installer starts the XFree86 subsystem and sets the correct localization environment, including the localized environment variables, font set, and correct keyboard ing. Then, users are allowed to interact, this completes the entire system installation process with user intervention.
The general process of the installation process is as follows:

2.1 customized kernel Installation
A good installer kernel is closely related to the installer and must be complete and streamlined. A complete kernel means that if the installer needs to support certain functions, it must also provide corresponding support in the kernel. A streamlined kernel is a function that is not required by the installer. The kernel must not be supported and can exist as a module. In this way, the customized kernel is very small, ensuring that the customized kernel and necessary hard drive modules can be put into the boot image.
For example, for a set of kernel 2.4.3 options, the options that are not included in the following set of options can be omitted when you customize the kernel of the installer)
Loadable module support
[*] Enable loadable module support: supports Loading modules into the kernel
[*] Kernel module loader transfers the Kernel module loader to the Kernel
Processor type and features Kernel support Processor type
(386) Processor family select 386 compatible mode to compile the kernel
Toshiba Laptop support Toshiba notebook support as module
(Off) High Memory Support does not Support Memory larger than 2 GB
The 386 compatibility method is used to ensure the installation program has good compatibility. To some extent, the speed is not a metric to measure the installation program. A good installer should be highly stable and compatible.
General setup General options
[*] Networking support kernel-level network support
[*] PCI support kernel-level PCI bus support
(Any) PCI access mode PCI hardware access mode
[*] EISA support kernel-level eisa bus support
[*] Support for hot-pluggable devices supports hot swapping devices
[*] System V IPCSystemV inter-process communication mechanism
(ELF) Kernel core (/proc/kcore) format Kernel file format is ELF
Kernel support for a. out binaries Kernel module supports a. out File
<*> The Kernel support for ELF binaries Kernel supports the ELF format.
Kernel support for MISC binaries Kernel module supports other formats
Kernel support for network support and IPC mechanisms is required, because many programs on Linux use these methods for inter-process communication even if they do not communicate over the network. ELF Kernel support is also required, because the installer needs to use the initial memory image initrd). In this way, you need to call the program to complete some initialization work, this requires the kernel to support the ELF executable file format. Other support for PCI and EISA devices is required to improve the compatibility of kernel hardware.
Parallel port support.
Parallel port support modular Parallel port support
PC-style hardware PC hardware
[*] IEEE 1284 transfer modes IEEE 1284 transmission mode supports device self-check)
For the parallel port, to automatically detect devices connected to the parallel port, the IEEE 1284 transport mode must be supported into the kernel. For parallel devices that do not support the IEEE 1284 transmission mode, the system cannot perform automatic detection.
Plug and Play configuration
Plug and Play support modular Plug-and-Play Device support
ISA Plug and Play support modular ISA Plug-and-Play Device support
In the 2.4.x kernel, there are some errors in the support for ISA Plug and Play devices. For some devices, if this option is set to the kernel, the devices cannot work normally. Therefore, we recommend that you use the kernel module mode to support such devices during kernel customization.
Block devices introduces support for Block devices
<*> RAM disk support core supports RAM disks
(4096) Default RAM disk size
[*] Initial RAM disk (initrd) support
Kernel support for the initial RAM disk. Because the installer needs to set the initial memory image to load the device module, this option is required for the installer.
Other options exist as device modules and can be placed in the initial memory image as needed.
Multi-device support (RAID and LVM)
[*] Multiple devices driver support (RAID and LVM)
<*> RAID support transfers the device module md. o to the kernel.
If you do not place md. o in the kernel, the raid partition cannot start the system as the root partition only in the module mode. This is mainly because the raid device needs to read and write the hard disk at the beginning of startup to determine the location and type of the raid partition.
Linear (append) mode
RAID-0 (striping) mode
RAID-1 (FLUSHING) mode
RAID-4/RAID-5 mode
Multipath I/O support
Logical volume manager (LVM) support
To support software RAID devices and logical volume management partitions, you can customize these devices as kernel modules. To support the above special types of storage devices, mkinitrd is required to generate a correct initial memory image, the system can correctly install and check the file system, and must also provide initscript support for the Initial Startup Script ).
Networking options
Packet socket set package Protocol
<*> Unix domain sockets supports unix domain sockets
[*] TCP/IP networking Kernel support TCP/IP network
ATA/IDE/MFM/RLL support supports low-end storage devices of ATA/(E) IDE and ATAPI.
<*> ATA/IDE/MFM/RLL support
IDE, ATA and ATAPI Block devices
<*> Enhanced IDE/MFM/RLL disk/cdrom/tape/floppy support
<*> Include IDE/ATA-2 DISK support
<*> Inculde IDE/atapi cdrom support
Inculde IDE/atapi tape support
<*> Inculde IDE/atapi floppy support
SCSI emulation support
IDE chipset support/bugfixes as kernel support
For common IDE device support, it is best to break into the kernel to ensure that the installer can be started directly from the hard disk, floppy disk, and optical drive without additional settings.
SCSI support
All supported SCSI devices are used as kernel modules. These modules are compressed and stored in the initial memory image so that the system can insert the correct device driver module when using the SCSI controller.
Network device support
[*] Network device support
Supports network devices, including ARCnet, Appletalk devices, Ethernet, PPP, SLIP, and Token Ring. Drivers of these devices can be used as device modules.
ISDN subsystem
ISDN support
To support ISDN devices, all hardware drivers of the underlying ISDN card of the kernel are used as modules.
The Old CD-ROM drivers (not SCSI, not IDE)
[*] Support non-SCSI/IDE/atapi cdrom drivers
For specific old CDROM devices, their drivers also exist in the form of modules.
Input core support
Input core support
Keyboard support
Mouse support
Joystick support
Event interface support
Enable HID support for USB devices
Character devices
[*] Virtual terminal
Allows you to run several virtual interruptions on a virtual terminal. You can use Alt-<function key> to switch between them.
[*] Support for console on virtual terminal
Set a virtual terminal as the system console
Standard/generic (8250/16550 and compatible UARTs) serial support
Generate serial. o. Allow serial mouse, serial modem, and other similar devices to connect to the standard serial port.
File systems
Kernel automounter support
Reiserfs support
Dos fat fs support
MSDOS fs support
VFAT (Windows-95) fs support
Simple RAM-based file system support
ISO 9660 CDROM file system support
[*] Microsoft Joliet CDROM extensions
NTFS file system support
[*]/Proc file system support
[*]/Dev/pts file system for Unix98 PTYs
ROM file system support
<*> Second extended fs support
Network File Systems as a module
Partition Types
[*] Pc bios (MSDOS partition tables) support
Native Language Support as a module
This option enables the customized kernel to support/proc, ext2, And/dev/pts file systems, you can use the insert module to support the fat, vfat, ntfs, cdrom, reiserfs, and rom file systems. Supports the NFS file system and kernel-level automatic mounting. At the same time, the local language is supported when the file system is mounted. The default value is iso8859-1.
Console drivers
[*] VGA text console
[*] Video mode selection support
MDA text console (dual-headed)
Frame-buffer support
Allows the Linux text mode to use VGA or Frame buffer. Frame-buffer is required for the installer, which enables the installer to start XFree86 in fbdev mode.
Sound
Sound card support
For sound card support, the kernel can customize the device drivers of each sound card into modules.
USB support
Support for USB
[*] Preliminary USB device filesystem
The usb file system must be customized to the kernel so that you can detect the installed usb device through the/proc file system. Usb bridges (uhci, ohci) and drivers of different devices can be used as kernel modules.
2.2 custom memory initial image
Because the kernel of the customized installer requires a very small kernel, the installer must support as many hardware devices as possible. To support as many hardware as possible, especially for special storage devices, we need to customize the required part when starting the image, such as common SCSI controllers and driver modules of non-standard IDE controllers. In this way, when the kernel tries to use a hard disk or other storage devices, its device driver has been loaded in advance.
After the kernel is transferred to the memory, if there is an initial memory image initrd), the control will go to it and execute the configuration script linuxrc. The initial memory image enables the boot loader to load a ramdisk, which can be attached as the root file system and can run applications on it. After that, the new root file system can be mounted from different devices, such as optical drives or hard disks ). After a new file system is mounted, the initial memory image used as the root partition will become the directory/initrd or be uninstalled.
The use of the memory initial image initrd will divide the system boot process into two phases. The Initial Startup kernel only needs to keep the smallest driver set, when an additional driver module must be loaded at startup, it is then loaded by the memory initial image. For example, you must create an initial memory image after using the software RAID method to manage the hard disk and using the RAID 1 partition as the root partition of the system. In this case, the initial memory image contains the device module raid1.o, the system command insmod, and a shell script linuxrc, which must contain:
Insmod raid1.o
When using the memory initial image, the system boot process is as follows:
The boot loader loads the kernel and initializes the ramdisk.
The kernel changes the initial memory image to a normal ramdisk and releases the memory used by the initial memory image.
The initial memory image is attached to the root partition, which allows read/write operations.
Execute linuxrc. It can be any legal execution program, including shell scripts. This program runs in the uid 0 mode and completes the basic work of init ).
When linuxrc is terminated, the real root file system is mounted.
If the/initrd directory exists, initrd is moved here. Otherwise, initrd is uninstalled.
Complete the normal boot process on the root file system. For example, if/sbin/init is executed for a normal system, the control will go to the startup process that is well known. For the installation program, it only needs to transfer the control to the first stage of the installation process, which completes subsequent installation environment loading and further device initialization.
Creating an initial memory image is actually creating a file that contains an ext2 file system. It can be linked to a local file system by loop. The following shell section allows you to create an initial memory image:
Dd if =/dev/zero of =/tmp/initrd bs = 1 k count = 2000
Creating a K file must not contain fragments.
Mke2fs/tmp/initrd
Create an ext2 File System
Mount-t ext2/tmp/initrd/mnt-o loop
Mount this file as a loop File System to the/mnt directory
Create the required path and file:
Mkdir/mnt/dev
Mknod/mnt/dev/tty1 c 4 1
Mkdir/mnt/lib
Cp raid1.o/mnt/lib/
Mkdir/mnt/sbin
Cp/sbin/insmod/mnt/sbin/
Cp/sbin/ash/mnt/sbin/
......
Umount/mnt
Uninstall this File System
Gzip-9/tmp/initrd
Cp-f/tmp/initrd.gz/boot/initrd. img
Rm-f/tmp/initrd.gz
This memory image file is generated.
In order to generate a memory image file, the kernel must enable ramdisk to support and support the initial ramdisk during compilation. All objects in initrd that execute programs, such as executable file formats ELF and file system EXT2) it must be compiled into the kernel so that the memory image file generated by you is available normally.
By default, the root device is specified in the standard settings of the kernel. You can also set it by rdev or by passing the parameter root = xxx on the command line. You can change the root device in the initrd environment. First, the system needs to mount/proc and make the following files available:
/Proc/sys/kernel/real-root-dev
/Proc/sys/kernel/nfs-root-name
/Proc/sys/kernel/nfs-root-addrs
Real-root-dev can be changed by writing a new root file system device number to it, for example
# Echo 0x301>/proc/sys/kernel/real-root-dev
All in all, the main purpose of creating an initial memory image file is to configure the kernel module during system installation and startup. At this time, the initial phase of the installation process will work as follows:
When the system is started from a floppy disk or other media with a minimum kernel, it must support the ramdisk, initial memory image, ELF executable file, and ext2 File System) and load the initial memory image.
/Linuxrc decides the next step:
Mount a real root file system, including processing device types, device drivers, file systems, and other information.
The publishing media of the installer, such as CDROM, network, and tape ...). This can be done by asking users, automatic detection, or hybrid methods.
/Linuxrc loads required device driver modules.
/Linuxrc creates and manages the root file system.
/Linuxrc is written in the root file system and any other mounted file systems, set/proc/sys/kernel/..., and terminate.
Mount the root file system.
The boot loader is read into the memory.
The initial memory image/initrd with a module set configured in the boot loader can be modified and uninstalled ).
Complete the installation tasks attached during system boot.
2.3 customize the minimal running environment
The runtime environment of the installer is the second stage of the entire installation process. It is loaded into the memory by the first-stage installer after the kernel and initial memory image run. After that, the installer starts to run on it. The minimal installation environment is the minimum Linux operating environment.
The customized installation environment is closely related to the features provided by the installer. Generally, the installer must open multiple control terminals. Therefore, to facilitate debugging, the installation environment should have a complete shell command environment. In addition, to support graphical display, the installation environment also requires the XFree86 system and the GtkQt library environment. gtk-engine may also be required to support texture display. For installation programs that support multiple languages, the glibc localization environment, multiple font sets, and different keyboard ing methods are required. In addition, the driver module of the hardware devices supported by the installer should also be placed into the running environment of the installer.
The installation environment generally includes the following content:
Runtime Library, including the dynamic library required for running programs
Driver Module file, including the device and service module to be supported by the installation program
System commands, including various system commands
Multi-language environment, including keyboard ing, localization environment, font
XFree86 system, including XFree86 servers
The script interprets the running environment, such as Perl or Python.
Installer
To minimize the running environment, the library must be the most streamlined during the build and installation process. That is to say, each library file must be used by at least one command or part of the installer. At the same time, during the copy process, use the strip command to dial all debugging information. Check which dynamic libraries are used by a command to use the command ldd.
For example, when the installation program contains the fdisk command, to check the required Runtime Library, you only need to run the following command:
Ldd 'which fdisk'
So we can know that fdisk requires dynamic library libc. so.6 and ld-linux.so.2. The next step is to copy the two libraries to the running environment of the installation program and run them at the same time.
Strip libc. so.6
Strip ld-linux.so.2
Call all debugging information.
The following uses Mandrake 8.0 as an example. Let's see what the installation environment contains. The installation program of Mandrake 8.0 is stored in the mdkinst directory of the disc. the directory structure of the installation program is as follows:
/Etc
Contains the configuration options of the pcmcia device, sysconfig directory, color palette, and Imlib missing settings.
/Lib
Contains the system Runtime Library lib * and supported driver module sets.
/Usr/X11R6/bin
Includes XFree86 servers, including XF86_FBDev and XF86_VGA16.
/Usr/X11R6/X11
Contains the XFree86 server font and localization environment.
/Usr/bin/
This is the most critical directory of the entire Installer. It contains the system commands required for executing the installer, the installer source code, and the install2 file is the main control file of the installer, the source programs of all the installation programs are stored in the perl-install directory.
/Usr/lib/
The runtime libraries supported by multiple languages are saved in the gconv directory, the modules required for perl5 running are saved in the perl5 directory, and other settings related to localization and gtk are saved.
/Usr/share
The console fonts are saved in lelefonts. The program maps and desktop topic maps are saved in the gtk directory and all the files under this directory *. xpm ,*. png file. The localization environment of glibc is saved in the locale directory, and the keyboard ing is saved in the keymaps and xmodmap directories respectively. The information file of the device contains the correspondence between the device ID and the device driver) save it in the ldetect-lst directory.
The system Runtime Library saved in the/lib/directory:
System RPM package dynamic library
Glibc Ld-linux.so.2, libc. so.6, libcrypt. so.1, libdl. so.2, libm. so.6, libnsl. so.1, California, libnss_files.so.2, libnss_nis.so.2, libresolv. so.2
Libext2fs2 libcom_err.so.2, libe2p, libuuid. so.1
Libdb-3.1.so db3
Db3-devel (libdb. so.2)
Zlib1 Libz. so.1
Libpng2 libpng. so.2
Libgtk + 1.2-devel libgtk-1.2.so.0, libgdk-1.2.so.0
Libimlib1 libgdk_imlib.so.1
Libglib1.2 libglib-1.2.so.0
Libglib1.2-devel libgmodule-1.2.so.0
Libbzip2_1 libbz2.so. 1
Lvm liblvm. so
Rpm librpm. so.0, librpmio. so.0
The XFree86-devel LibX11.so. 6, libXext. so.6.
XFree86-libs libXi. so.6
XFree86-server-common (libfont. so.1)
Freetype libttf. so.2
Table 2-1
Commands supported by the system saved in the/usr/bin/directory:
System rpm package system commands
Ash
Console-tools Consolechars
Cpio
Gzip
E2fsprogs badblocks, mke2fs, resize2fs, dumpe2fs
Util-linux fdisk, rescuept
Modutils insmod _, rmmod
Raidtools mkraid, raidstart,
Bzip2 bzip2
Rpmtools packdrake, parsehdlist
Perl-base Perl
Lvm pvcreate, pvdisplay, vgchange, vgcreate, vgdisplay, vgextend, vgremove, vgscan, lvcreate, lvdisplay, lvremove
Kernel-pcmcia-cs Ifport
Dosfstools Mkdosfs
Reiserfs-utils mkreiserfs, resize_reiserfs
Table 2-2
In addition, because the perl language has some system functions, some commands can also be compiled in perl to reduce the running environment. These commands include:
Basename, bug, cat, chmod, chown, cp, dd, df, dirname, displaySize, dmesg, du, e2fsck, fsck. ext2, getopts, grep, gunzip, head, head_tail, header, hexdump, insmod, kill, ln, loadkeys, ls, lsmod, lspci, mkdir, mknod, mkswap, modprobe, more, mount, pack, ps, raidstop, report_bug, rights, rm, rmdir, route, sh, sort, strings, swapoff, swapon, sync, tail, tr, true, umount, uncpio, unpack, which