Analysis of the entire process of Linux mini-System Construction

Article Title: analysis of the entire process of Linux mini-system construction. Linux is a technology channel of the IT lab in China. Includes basic categories such as desktop applications, Linux system management, kernel research, embedded systems, and open source.

The Mini Linux system to be built in this article can only run on a specific single machine. If you are interested, you can improve it on the basis of this system, A general plug-and-play system can be built on most general PC machines. However, this is no longer the topic of this Article. If you are interested, you can use my email to discuss the details.

Our target Linux system runs on an ordinary Intel 386 PC, which can be replaced by Flash disks instead of hard disks. If a Flash disk is used, it must be able to start from the Flash disk, and the size of the Flash disk must be 16 MB or more. We hope that the user can directly go to the X Window graphical interface and run the specified program as soon as the machine starts. You do not need to enter the user name and password to log on.

The goal we set is a bit like an X Terminal workstation. A little improvement can also be made into a simple diskless form, that is, do not even use a 16 M Flash disk. However, this is beyond the topic of this article. If you are interested, you can come and discuss with me.

System Startup

Because we need to consider starting from the Flash disk, we choose LILO as our Boot Loader instead of GRUB. This is because GRUB has a strong ability to identify hard disks and file systems. Flash disks are not standard hard disks, and we do not necessarily know GRUB, if not, GRUB will be self-defeating. LILO is much simpler. It writes a small program to the MBR starting from the hard disk. This program directly reads the Kernel Image and loads it into the memory without going through the file system. In this way, the insurance coefficient is greatly increased. It also gives us the freedom to choose a file system. So how do we install LILO?

First, we need to find an ordinary IDE Hard Drive of about 800 M, and connect it to the IDE of the target machine. In this way, on our target machine, IDE1 is mounted with a Flash disk and IDE2 is mounted with a work hard disk. We use standard steps to install a Debian GNU/Linux system on the standard hard drive of ide2. Of course, if readers do not have Debian, they can also install the Red Hat system. After installing the work system, we must first cut down some work and delete unnecessary services and X Windows. The purpose of this operation is to increase the system startup speed, because in our subsequent work, we must constantly restart the machine, so the startup speed is critical to our work efficiency.

After installing the working system, create an Ext2 File System on the Falsh disk, and use the mke2fs command. Because the Flash disk is connected to IDE1, in Linux, its identity is/dev/hda. During operations, the author divides the entire Flash disk into a whole partition. Therefore, when calling mke2fs, the processing is/dev/hda1. Readers should be able to directly create an Ext2 File System on/dev/hda without Partitioning in advance.

After the file system is completed on the Flash disk, you can copy a compiled kernel image file vmlinuz to the Flash disk. Note: You must copy the vmlinuz image file to the Flash disk before installing LILO on the Flash disk. Otherwise, LILO will compress lilili, because it will not find the position of the Kernel Image on the Flash disk, and the Flash disk will not start. In addition, if readers and friends use a compressed file system on the Flash disk, LILO will have problems at that time. Although it can correctly find the starting position of the Kernel Image on the hard disk, however, it cannot process the Kernel Image that has been recompressed by the file system, and does not know how to expand it to the memory.

After copying the Kernel Image, We can edit a lilo. conf file, which can be placed on the work system. However, note that you can write the correct path to the index file name in lilo. conf. These path names are all the path names that appear on the work system. For example, if the Flash disk is mounted under the/mnt directory, the path name of vmlinuz in lilo. conf is/mnt/vmlinuz. Be sure not to make a mistake. Otherwise, if the LILO of the work system is accidentally damaged, it will be troublesome. After you have edited lilo. conf, run the lilo command again. Be sure to tell it to use the new lilo. conf file instead of/etc/lilo. conf.

After LILO is installed, we can immediately restart and test it. First, in the BIOS, set it to start from IDE1. If we see the LILO prompt, press enter to see the message output from the Kernel, even if LILO is successfully installed. Remember to update LILO every time we update the Kernel Image on the Flash disk. That is to say, run the lilo command again.

Compile the kernel

After the installation of LILO was successful, we began to consider compiling a new kernel. Of course, to compile a new kernel, we must first enter our work system. There are two ways to enter the work system. One is to enable IDE2 In the BIOS. Of course, this requires that when the work system is installed, install LILO on/dev/hdb. The other method is to start from IDE1 without changing the BIOS settings, but when you see the LILO prompt, to enter linux root =/dev/hdb1, the first linux is in lilo. conf defines an entry. We only use the Kernel Image specified by this entry, but use/dev/hdb1 as the root file system. The two methods may sometimes be better than the other, which is more convenient. This depends on the specific situation. However, their settings do not conflict with each other.

When compiling the kernel, we should be familiar with the situation of the kernel because it is only used by one machine. On the other hand, in order to reduce unnecessary complexity, we decided not to use the support of the kernel module, but to compile all the required things directly into the kernel. In this way, all necessary functions are added to the compiled Kernel on a common 586 motherboard, generally less than 800 KB. Therefore, this method is feasible. It also reduces the complexity of init scripts. In terms of running, because the required kernel code is to be loaded into the memory, it will not cause a waste of memory.

On our target platform, we want to use USB storage devices. Another thing to note is the support for Frame buffer. This is mainly to support XFree86. In general, if our video card is directly supported by XFree86, it is of course the best, so we do not need the Kernel support of frame buffer. However, if XFree86 does not support our video card, we can consider using the VESA mode. However, the XFree86 VESA card does not run well, and there are security issues. Sometimes the screen will appear when you start and exit X Window. Therefore, we can use the frame buffer in the vesa mode of kernel, and then use the xfree86 linux frame buffer driver. In this way, the screen is invisible, and there is no security problem.

Devfs is also a topic of interest to us. If the kernel does not use devfs, the root file system on the system must have all the content under the/dev directory. You can use the/dev/MAKEDEV script or mknod to create the content one by one. This method has its own advantages. However, its disadvantage is that it is troublesome and its status is inconsistent with that of the kernel. On the contrary, if devfs is used, we no longer have to worry about anything in the/dev directory. The project under the/dev directory has the kernel code. The actual usage is not obvious to the memory consumption. So we chose devfs.