Create a mini Linux system by yourself

This article will lead you to build a mini Linux system. It occupies much less than 16 MB of hard disk space, but includes the XFree86 X Window System.

Target

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.

Busybox

With LILO and kernel image, we will arrange the root file system. Since the flash disk space is only 16 MB, it can be said that this is our biggest challenge. Here, we will first introduce you to BusyBox, a common tool for configuring the root file system in a small embedded Linux system.

Busybox is the famous Bruce Perens of Debian GNU/Linux. It is first developed and used in Debian installation programs. Later, many Debian developers contributed to the development of busybox's current maintainer Erik Andresen, who suffers from cancer, but is a good free software developer.

Busybox compiles a single independent execution program called busybox. However, it can execute the ash shell function and dozens of small applications based on the configuration. This includes a mini vi Editor, an indispensable/sbin/init program in the system, and other such as sed, ifconfig, halt, reboot, mkdir, mount, ln, ls, echo, cat... and so on, these are essential to a normal system. But if we take the original program, the volume of the program will be combined. But busybox has all these functions, and the size is only about 100 K. In addition, you can decide which applications to compile in busybox based on your needs. In this way, the volume of busybox can be further reduced.

Busybox is easy to use. If you create a symbolic link, for example, ln-s/bin/busybox/bin/ls, busybox will execute the ls function when executing/bin/ls, the command line parameters are also processed in ls mode. Another example is ln-s/bin/busybox/sbin/init. In this way, we have an indispensable/sbin/init program for system running. Of course, the premise here is that you have compiled the functions of these two programs in busybox.

Note that the/etc/inittab format recognized by the INIT program of busybox is very simple and is different from the regular inittab file format. Readers should pay attention to different syntaxes when writing inittab for the init of busybox. We will not discuss the details here. Please refer to the user manual of busybox.

From startup to Shell

After busybox is installed, we can consider restarting until we enter the shell prompt. Before that, we need to prepare several important files under the/etc directory, and copy the library used by busybox.

By using the LDD command, the path name of the binary program to be analyzed can be known as a binary program or the dependency between a library file. For example, busybox depends on libc. so and ld-linux.so, we have this knowledge, you can copy all the required Library to the flash disk. Because our flash disk is not big, it is not small, it is 16 Mb in size. There are not many problems with using glibc files directly. If readers and friends have special needs and think that glibc is too large, you can consider using uclibc, which is a very small libc library and has no full functionality of glibc, but it is enough for an embedded system. This article will not introduce uclibc any more.

After the library program is copied, we can consider the system startup steps. Start lilo first, then kernel. After the kernel is initialized,/sbin/init is called. Then, init explains that/etc/inittab is used to run various things. Inittab guides init to call a most important system initialization program/etc/init. d/rcS. We will mount each file system in the rcS. In addition, we will also call the dhcp program in the rcS to mount the network. After the RFM execution is complete, init will open a shell or getty + login on a console according to the inittab instructions, so that the user will see a prompt prompting the user name. For the sake of simplicity, let's go to shell first, and then wait until the debugging is successful, and then change to directly go to X Window.

We have mentioned the inittab syntax above, and hope readers can check the authoritative busybox user manual. Here, we will first talk about the composition of the file system.

File System Arrangement

As you can see, our root file system uses the standard ext2 file system to avoid troubles. Because our hard disk space is small, less than 16 MB, and we need to put X Windows on it, if we use ext2, the limited space of the Flash disk will soon be exhausted. Our only choice is to adopt an appropriate compressed file system. The contents in the/usr directory do not need to be rewritten when the system is running. We decided to select the read-only compressed file system cramfs to accommodate all the content under the/usr directory.

Cramfs is a small file system developed by Linus Torvalds for embedded systems. Because it is read-only, although it adopts zlib for compression, it can still achieve efficient random reading. Since cramfs does not affect the speed at which the system reads files and is a highly compressed file system, it is a good choice for us.

First, we will make all the content in the/usr Directory into a cramfs image file. This can be done by running the mkcramfs command. After obtaining the usr. img file, we need to consider how to mount the image file to become an available file system when the system is running. Because the image file is not a block device in the general sense, we must use the loopback device to complete this task. Specifically, add a mount command in the previous section of the/etc/init. d/rcS script mentioned above:

Mount-o loop-t cramfs/usr. img/usr

In this way, you can mount the cramfs image file usr. img to the/usr directory through the loopback device. Oh, by the way, because the loopback device is used, readers should not forget to add the Kernel support for this device when compiling the kernel. For the future operation of the system, the effect of this mount is transparent. The compression efficiency of cramfs is generally nearly 50%, and most of the content on our system is located under the/usr directory. As a result, we may have to use an 18 M Flash disk, now it may only take 11 Mb. A 14 M/usr directory is compressed to only 7 M.

We have taken into account the compression problem above. We also need to consider that Flash disks are not as common hard disks after all, but they are not very good after multiple writes. Therefore, we consider that where multiple writes are required, use the memory. We want to use tmpfs to complete this task. As for the comparison between tmpfs and the classic ramdisk, we will not talk about it here. In general, tmpfs is more flexible. The size of tmpfs is not as large as ramdisk and can be increased or reduced as needed. We chose to make several directories such as/tmp and/var into tmpfs. You only need to add two lines of text similar to the following in/etc/fstab:

None/var tmpfs default 0 0

Then, do not forget to add Mount-A in the/etc/init. d/RCS Near the start point. In this way, all the file systems specified in/etc/fstab can be mounted.

X Window

Readers may think that the installation of X Window may be complicated. As a matter of fact, the installation of X Window is very simple because the above shelf is ready. Just copy several key programs. Generally, only the bin and Lib directories under the/usr/x11r6 directory are required. Then, you can make significant reductions based on your own needs. For example, if you have an open XFS font server on your LAN, you can delete all the local fonts and use the remote font server. If you only need to run a limited program, do not forget to delete all useless libraries. In addition, you can delete all the redundant X Window drivers, and only retain the driver required by the local display card.

Of course, it is inevitable to perform multiple tests.

Other skills

SSH is a good tool if your working system is connected to the local machine through a LAN. In addition, the SCP in SSH is similar to the common CP Copy Program, which is very convenient. Using SSH and SCP to share files and perform remote trials, you don't need to run around in the office.

If you need an X Server and XFS font server running on MS windows, consider the xfree86 system included in Red Hat's cygwin toolbox.

References

1. busybox site: http://www.busybox.net
2. Linux from scratch, do it yourself, start from scratch to make a Linux system: http://www.linuxfromscratch.org
3. uclibc site: http://www.uclibc.org
4. cygwin site: http://www.cygwin.com

About the author

Zhao Wei, a freelancer. My Web diary is located in http://www.advogato.org/person/zhaoway. The above lists other articles I posted on the Internet. You are welcome to discuss your questions with me.

Full text source: IBM developerworks Chinese website