Introduction:This article describes how to customize a Linux system installation disk based on an existing RedHat Linux system installation disk.
Release date:March 01, 2005
Level:Elementary
Access:6010 views
Comment:0 (View | add comments
-Logon)
1 Introduction
Generally, for some practical application, an operating system release disk containing all the recently updated RPM packages is required to complete all update operations at one time during installation, or you want to customize an operating system release disk with its own characteristics. For example, you can create an RPM package and add your own applications to the operating system. This is done once during system installation, create an operating system release disk that contains your own products. These all need to be regenerated, and it is also necessary to generate the installation disk, because the operating system publishers will always update and process some vulnerabilities after each formal release, some of them are security-related. You can add these bug fixes to your custom installation disk when you regenerate the installation disk, to support newly developed drivers for some devices, you also need to regenerate the installation disk.
In some embedded applications, because of its specific requirements on the operating system, there is no need for the many features that are included in the current operating system installation disk, for example, Fedora Core 2 currently has four installation disks, which contain many other applications, such as office, entertainment, and games. Some specific applications do not need so many features at all, therefore, they often need to be based on a version of the operating system, and then make corresponding reductions to meet the actual needs of specific applications, without the need for other redundant functions. Therefore, you can choose a software package based on your own or actual needs to customize the operating system installation to meet the needs of specific applications.
Before customizing the operating system installation disk, we must have a blueprint as the basis for the installation disk, such as red hat 9.0 installation disk or Fedora Core 2 installation disk, it can also be the ISO file of the Red Hat 9.0 or Fedora Core 2 installation disk, which can be downloaded from the Red Hat website or other websites. Suppose we already have the Fedora Core 2 installation disk. Let's take a look at the content in the installation disk of Fedora Core 2.
In the installation disk, there is a directory named fedora, which contains the core content of the release disk, as follows:
drwxr-xr-x 2 root root 2048 May 13 2004 basedrwxr-xr-x 2 root root 77824 May 13 2004 RPMS |
The RPMs directory contains the main part of the ora Core 2 release disk, which is an RPM file. The RPM package usually contains binary executable files, related configuration files and documents. For more information, see the RPM help.
The base directory contains some files required during installation, such as comps. XML file, which defines which components contain the RPM packages and the dependency between the RPM packages. Note that in the comps. the XML file indicates which component has the RPM package using the RPM package name, rather than the package file name. For example, the perl-5.8.3-18.i386.rpm file name, the RPM package name represented in comps. XML is Perl. For the comps. xml file, we will further explain it later. Another important file is the hdlist file, which contains most of the header files of all RPM packages in the RPM directory. This means that the dependency in the RPM package can be determined by reading the hdlist file, you do not need to read all RPM packages. Another role of the hdlist file is to map the package name to the file name, such as ing the Perl package name to the perl-5.8.3-18.i386.rpm, which means if you want to update the RPM package or add your own package to the RPM directory, you need to update the hdlist file, which will be described later.
Back to Top
2 RPM operation
RPM (RedHat package management) is a system package management tool developed by RedHat in Linux. Its goal is to make the package installation and uninstallation easier. It can verify whether a package has been correctly installed, simplify the package creation process, and create the entire package from the source code, it can be used in different architectures. The RPM System has become the de facto standard for the Linux system package management tools and has been transplanted to many commercial UNIX systems.
The RPM package is identified by the package tag. The package tag contains the software name, software version, and release version of the package. The package also contains information such as the package creation time, package content description, size of all files in the installation package, and digital signature to verify the package integrity. The RMP package also contains the file information in the package, including the file name of each file, permissions of each file, owner and owner of the file, MD5 checksum of each file, file Content.
The RPM package management system provides the following functions: install a new package, uninstall the old package, upgrade an old package to a new package, and obtain information about the installed package.
Red Hat release disks are mainly composed of RPM packages. The RPM package name contains a suffix: arch. rpm and arch refer to the architecture. For intel platforms such as i386, i586, and i686, the packages you install must match the version of the shared library on the machine. If you find that an RPM package is not installed, you can install it by yourself. At any time, you can (must be a root user) install the RPM package. For more information about RPM commands, see.
Back to Top
3 RPM package creation process
To create an RPM package, perform the following steps:
To perform the packaging, RPM requires a series of directories for creation. A normal directory structure usually consists of a top-level directory and five sub-directories. These five subdirectories are:
In addition to these five main directories, there are usually directories about the target platform of the RPM package in the RPMs or srpms directory. For example, i386, i586, and i686 represent intel-compatible CPU platforms. The RPM package under the noarch directory represents any platform that can be executed.
3.1 spec File
The spec file is the center of the entire RPM package creation process. It acts like the MAKEFILE file during program compilation. The spec file contains the required information for creating an RPM package, including which files are part of the package and which directory they are installed in. This file is generally divided into the following sections:
(1) preamle (preface)
The content displayed when the preface contains information about the user request package. It can contain the function description, software version, copyright information, and the package Group of the package. Summary is a line of description about the software package. Name is the base name of the software package. version is the version number of the software, and release is the version number of the RPM, if an error in the spec file is fixed and the new RPM of the same version of the software is released, the release number should be added. License should provide some license terms (such as "GPL", "commercial", "Ware ware"), group identification software type. Programs that try to help people manage RPM are usually listed by group
Rpm. You can see a list of groups used by red hat in the usr/share/doc/rpm-4.0.4/groups file (assuming your installed RPM version is 4.0.4 ). However, you can also use other group names. Source0, source1, etc. name these source files (usually tar.gz files ). % {Name} and % {version} Are RPM macros which are extended to the RPM names and versions defined in the header.
Note that do not include any paths in the source statement. By default, RPM searches for files in/usr/src/RedHat/sources. Copy or link your source files to the file. (To make spec files portable as much as possible, avoid embedding them in the hypothetical path on your own development machine. Other developers can instruct RPM to search for source files in other directories without modifying your spec files .)
The following part starts with the % description line. You should provide more description of the software here, so that anyone can view it when querying your software package using rpm-Qi. You can explain what the software package is doing, describe any warning or additional configuration instructions, and so on.
(2) Prep Section
The prep section is used for actual packaging preparation, which is indicated by the Section prefix % prep. In general, the main task of this section is to check whether the tag syntax is correct, delete the old software source program, and decode the tar file containing the source program. If a patch file is included, apply the patch file to the unwrapped source code. It generally contains two Commands: % setup and % patch. % Setup is used to unbind the software source code package. Execute % patch to add the patch file to the Undo source program.
% Setup
-N newdir --------- unpack the compressed software source program under the newdir directory.
-C --------------- create a directory before unlocking the source program.
-B num ------------ extract the num source program when multiple source programs are included.
-T ---------------- do not use the default decompression operation.
For example:
% Setup-T-B 0
/* Unlock the first source program file. */
% Setup-C-N newdir
/* Create the directory newdir and unbind the source program under the directory. */
% Patch
% Patchn ------- here n is a number, indicating that the nth patch file is used, equivalent to % patch-P n
-P0 ----------- specify the first patch file and-P1 specify the second patch file. -S ------------ no information is displayed when the patch is used.
-B Name ------- Add name to the source file before adding the patch file. If this parameter is specified, the default source file is added to. orig.
-T ------------ delete all output files generated during patching.
(3) Build Section
This section is mainly used to compile the source code. It is represented by the Section prefix % build. This section is generally composed of multiple make commands.
(4) install Section
This section is mainly used to complete the commands that must be executed to install the software. It is indicated by the Section prefix % install. This section is generally composed of the make install command, but sometimes it also contains commands such as CP, MV, and install.
This section also specifies the script that runs when the package is installed on the user-installed system. Such a script is called the installation (uninstallation) script. It can specify the shell program segments that must be run by the system before, after, before, and after the package is installed. The verification script to verify whether a package has been successfully installed can also be specified in this section on the user-installed system.
(5) Clean Section
The content described in this section indicates that after creating a package, the script under this section is automatically executed to perform additional cleanup, which is indicated by the Section prefix % clean. Generally, this section uses the RM-RF $ rpm_build_root command and does not need to be specified.
(6) file list
This section specifies the list of files that constitute the package. It is represented by the Section prefix % files. In addition, it also contains a series of macro control file attributes and configuration information after installation.
% Files lists the files that should be bundled into RPM and can be set with permission and other information optional. In % files, you can use % defattr to define the default permission, owner, and Group. % defattr (-, root, root) will install all Files Owned by the root user, use any permission they have when RPM binds them from the build system.
You can use % ATTR (permissions, user, group) to overwrite the owner and permission of an individual file. You can use one line in % files to include multiple files. You can add % Doc or % config to the row to mark the file. % Doc tells RPM that this is a document file, so if you use -- excludedocs when installing the software package, this file will not be installed. You can also list file names without paths in % Doc. RPM searches for these files in the build directory and includes them in the RPM file, install them to/usr/share/doc/% {name}-% {version }. To
It is a good idea to include files such as readme and changelog in the form of % Doc.
% Config tells RPM that this is a configuration file. During the upgrade, the RPM will try to avoid overwriting the configuration you have carefully modified with the default configuration file packaged by the RPM.
Note: If a directory name is listed under % files, RPM will include all files in the directory. This is usually not what you want, especially for directories such as/bin.
(7) change log
This section mainly describes the software development records, which are expressed by the Section prefix % changlog. The content of this section is for developers to have a detailed understanding of the software development process, which is very good for package maintenance.
3.2 Create an RPM package
If we need to modify the RPM package, we first need to get the source code package. For example, if we want to modify the kernel, we can get the kernel source code RPM package from the Internet or on the CD, such as kernel-2.6.5-1.358.src.rpm, the source package undo: rpm-I kernel-2. 6.5-1.358.src.rpm, the content in this RPM will be stored in the/usr/src/RedHat/sources and/usr/src/RedHat/spec directories, the former stores the source code, patches and some configuration files, the latter stores the spec file corresponding to the package, such as the kernel-2.6.spec, now you can modify the kernel. Suppose we want to add another patch to the kernel, for example: mypatch-2.6.5.patch, You need to copy this patch file to the/usr/src/RedHat/sources/directory and then edit the kernel-2.6.spec file. You must first add the initial definition of your patch file at the end of the definition patch file, such:
............ Patch10000: linux-2.6.0-compile.patch # patch10010: linux-2.6.0-module-license.patchPatch10030: mypatch-2.6.5.patch/* newly added patch file definition */# End of patch definitions ............ |
Then add the Kernel Patching command after the file:
............ % Patch10000-P1 % patch10030-P1/* new patching command */# End of patch applications ............ |
If you want to make other modifications to the kernel, you can modify the corresponding file or add the corresponding file and then modify the kernel-2.6.spec file. After the spec file is modified, you only need to execute the rpmbuild-Ba kernel-2.6.spec to generate the desired RPM package. In addition, it should be noted that, in order to generate the kernel package as an example, if we want to generate a kernel-smp-2.6.5-1.358.i686.rpm package, there are some switch options in the kernel-2.6.spec file, for example, at the beginning of the file, you need to define which kernel RPM packages to create, such:
%define buildup 1%define buildsmp 0%define buildsource 1 |
Typically, after you run the rpmbuild-Ba kernel-2.6.spec command, a kernel-2.6.5-1.358.i386.rpm, kernel-source-2.6.5-1.358.i386.rpm, and source RPM package kernel-2.6.5-1.358.src.rpm is created. Therefore, when you need to create RPM packages that support SMP kernels, You need to modify the definition at the beginning of the kernel-2.6.spec file:
%define buildup 1%define buildsmp 1%define buildsource 1%define -target_cpu i686 |
In addition, define-target_cpu as i686 at the beginning of the file to create an i686 kernel RPM package and redefine some macros under the/usr/lib/RPM directory, for example, in the macros file under the current directory, You need to redefine arch and build_arch to i686. Finally, execute the command rpmbuild-Ba kernel-2.6.spec -- with SMP. Of course, if you modify the kernel, you must generate multiple kernel RPM packages for multiple arch, such as kernel-2.4.18-3-i586-smp.rpm and kernel-2.4.18-3-athlon.rpm.
Back to Top
4 operating system disk installation customization process
You need to copy the content on the original OS release disk to the local hard disk and generate several directories based on the number of distribution disks. For example, Fedora Core 2 has four disks, you need to generate four directories on the system, such as disc1, disc2, disc3, and disc4, and copy the contents of these four disks to these four directories respectively, then update the RPM package.
First, find the RPM package you want to update and replace the New rpm with the old one. You can also add or delete RPM packages as needed. Note that. add the new or deleted RPM package name to a component in the XML file, and pay attention to its dependency with other RPM packages. That is to say, the location of the package you placed should be appropriate, otherwise, it depends on an RPM package that has not been added to the system before it.
4.1 edit the comps. xml file
Before generating the installation disk, you must modify the comps. xml file. This file is used to inform the installer Anaconda. The user selects which packages should be installed in a group and defines how the packages are bundled during the installation process. In versions earlier than Red Hat 8.0, the corresponding file is comps, which is a simple text file. In Versions later than Red Hat 8.0, comps. XML replaces the original comps file. Comps. XML is an XML file that is easy to analyze and describe the content.
The comps. xml file begins with the description of the XML version and DTD assertions, and then enters the subject content of the file starting with the <comps> mark. For example:
<?xml version="1.0" encoding="UTF-8"?><!DOCTYPE comps PUBLIC "-//Red Hat, Inc.//DTD Comps info//EN" "comps.dtd"><comps> |
Comps. XML consists of three parts: the group list, which describes the different groups (or components) required during the installation process ), the group name, group description, and RPM package are included. The second is the group hierarchy, which divides the group into different classes and defines the order of the groups, this allows you to determine which groups need to be installed first, and finally a series of RPM packages and their dependencies.
The following describes the three parts of the comps. xml file:
(1) group list
Some attributes in A group need to be used during system installation. The following lists the attributes and how to use them. A group is defined within the <group> and </group> tags.
A simple group definition can be:
<group> <id>somegroup</id> <name>Sample Group</name> <default>true</default> <uservisible>false</uservisible> <description>This is a silly sample group</description> <packagelist> <packagereq type="mandatory">bash</packagereq> <packagereq type="default">cpio</packagereq> </packagelist></group> |
The following describes the meanings of some parameters in the Group definition:
(2) group hierarchy
It describes the tree hierarchy of a group. The group hierarchy is defined between the <grouphierarchy> and </grouphierarchy> tags, and consists of the defined <Category> tags.
A simple group hierarchy can be described as follows:
<grouphierarchy> <category> <name>Random Groups</name> <subcategories> <subcategory>somegroup</subcategory> </subcategories> </category></grouphierarchy> |
A class consists of the following attributes:
(3) RPM package
This section describes the RPM package to be installed, which is defined within the <package> and </package> labels. A simple RPM package can be used as follows:
<package> <name>bash</name> <dependencylist> <dependency>mktemp</dependency> <dependency>bash</dependency> <dependency>glibc</dependency> <dependency>libtermcap</dependency> </dependencylist></package> |
4.2 generate a complete comps. xml file
Comps. the RPM package in the XML file is automatically generated to form a complete comps. XML file, you need to install the comps-extras RPM package in the system, and then perform the following operations:
By adding your package to the comps. xml file, you can create your own release disk as needed to ensure that your package will be installed by default. One thing to note is the dependency between your updated package and other packages. This is what you need to handle. Pay attention to the location where your updated package should be placed. In addition, do not add or delete other spaces in the file. Before modifying comps. XML, You 'd better back up the original comps. XML for recovery.
4.3 re-compile the installer and adjust the installation phase
It is impossible for an installer to load the package at a time. It must be carried out in stages. This is often called "stage ". The program used in the first phase is very small. Only in this way can it be loaded from a floppy disk, a TFTP server, and so on. At this stage, the program usually contains only a streamlined Linux kernel and some necessary drivers (such as SCSI) in subsequent steps ).
To use a new RedHat installation, you will need a lot of images. The most obvious thing is the boot of the boot drive itself (installed from a soft drive or optical drive. IMG, but we also need to provide support for installation methods such as hard disks and network file systems.
RedHat provides a good script command to complete all operations with only one simple operation. The work of these scripts is to extract the content of some RPM packages and then generate the image of the program used for each installation step.
We must ensure that anaconda-runtime is installed:
#rpm -i anaconda-runtime-xxxxx-i386.rpm
Go to the/usr/lib/Anaconda-runtime directory. Here we will see some very useful scripts, such:
……NETWORKMODULES="$COMMONMODULES nfs 3c59x eepro100 tulip pcnet32ne2k-pci 8139too"…….. |
#cd /usr/lib/anaconda-runtime#./buildinstall ~/disc1/ |
The script command will be in ~ The/disc1/images directory updates some files.
4.4 generate a new hdlist File
During installation, the installer depends on the fedora/base/hdlist file on the CD, which contains necessary information for all available RPM packages, this information is used to display the usage of each package during installation and solve the dependency problem after the software package is selected.
The program used to generate the hdlist file is called genhdlist, which is generated by the Anaconda-runtime package. The current genhdlist has a new parameter -- withnumbers, which is used to record the Media Code of each RPM package in the hdlist file.
The process of step-by-step processing is as follows:
#rpm -i anaconda-runtime-xxxxx-i386.rpm#cd /usr/lib/anaconda-runtime#./genhdlist -- withnumbers ~/disc1 ~/disc2 ~/disc3 ~/disc4 |
The entire process only needs to execute a script, see Appendix 1: kernel-update.sh.
If you have added an RPM package to the system, you are advised to copy the content on the four disks to a directory before generating the installation disk, modify the script file in Appendix 1, and run the script, install the package on the network first to check whether the package dependency problem exists. If not, an installation disk can be generated.
Back to Top
5. generate an ISO Image
After the network is successfully installed on the current system, you can generate an ISO image and then perform the dial operation as follows:
# Build disk 1cd ~ /Disc1/* suppose we place the content of the first disk in addition */mkisofs-r-J-T-no-emul-boot-load-size 4-boot- info-table-V fedora-B isolinux/isolinux. bin-C isolinux/boot. cat-O/ISO/exm-disc1.iso. /* use mkisofs to generate an ISO image and put the generated ISO image in the/ISO directory */# Build disk 2cd ~ /Disc2/* use the same method to generate the second ISO, in sequence. */Mkisofs-r-J-T-V fedora-o/ISO/exm-disc2.iso. |
After an ISO image is generated, You need to test it. You can link it to a certain place, for example:
mount -o loop /iso/exm1-disc1.iso /mnt |
After an ISO (exm-disc1.iso) installation is generated, we can copy it to a Windows system, burn it with a burning program, and then install it from a CD for installation testing.
Back to Top
Appendix 1: kernel-update.sh
#!/bin/sh# current working directoryBASE=`pwd`# generate hdlistsmkdir -p $BASE/SOURCESecho echo Copying disc1 to SOURCES directory, please wait...cp -Rf $BASE/disc1/* $BASE/SOURCES echo Copying disc2 to SOURCES directory, please wait...cp -Rf $BASE/disc2/* $BASE/SOURCESecho Copying disc3 to SOURCES directory, please wait...cp -Rf $BASE/disc3/* $BASE/SOURCESecho Copying disc4 to SOURCES directory, please wait...cp -Rf $BASE/disc4/* $BASE/SOURCESecho echo Make sure anaconda, anaconda-runtime is installed...rpm -U $BASE/SOURCES/Fedora/RPMS/anaconda-*.rpm# generate hdlists*cd /usr/lib/anaconda-runtime./genhdlist --withnumbers $BASE/disc1 $BASE/disc2 $BASE/disc3 $BASE/disc4# generate the package ordering./pkgorder $BASE/SOURCES i386 |tee /root/pkgorder.txt./buildinstall --pkgorder /root/pkgorder.txt --version 1 --product "Fedora" --release "Fedora" $BASE/SOURCES$BASE/SOURCEScp -apRf $BASE/SOURCES/images/* $BASE/disc1/imagescp -apRf $BASE/SOURCES/isolinux/* $BASE/disc1/isolinuxcp -apRf $BASE/SOURCES/RedHat/base/* $BASE/disc1/RedHat/baseecho Cleaning up...rm -rf $BASE/SOURCES |
Start building with 50+ products and up to 12 months usage for Elastic Compute Service
1 on 1 presale consultation
24/7 Technical Support 6 Free Tickets per Quarter Faster Response
Alibaba Cloud offers highly flexible support services tailored to meet your exact needs.
A comprehensive suite of global cloud computing services to power your business
Payment Methods We Support
