This article will lead you to build a mini Linux system. It takes up with a hard disk space than 16M bytes, but includes X Window window system for Xfree86.
aims
This mini Linux system to build this article can only be run on a specific stand-in-one. If the reader friends are interested, improve the system based on this system, it can build common, can be in most regular Plug-and-play system on the PC. But this is not within the topic of this article, if you are interested, you can discuss the details of the details through my email and I discuss the details.
Our target Linux system runs on a normal Intel 386 PC, you can have a hard disk, or you can do not use Flash Disk instead. If you use the flash disk, you need to support startup from the Flash disk, and the size of the Flash disc is to be 16m bytes or more. We hope that the user starts starting, just enter the X Window graphical interface, run the prior specified program. You do not need to enter the username and password to log in.
This goal we set is a bit like an X Terminal terminal workstation. Slightly improvement, you can also make a simplicity of simplicity, that is, even 16m Flash dishes are not. However, this is also exceeded the topic of this article. If you are interested, you can discuss it with me.
System start
Because we have to consider starting from the Flash disc, we choose Lilo as our Boot Loader, not to use GRUB. This is to consider the GRUB has a strong ability to identify the hard disk and file system, and the Flash dish is not a standard hard disk, and we choose the file system grub does not necessarily know, and if you can't get it, GRUB will make it. And LILO is more simple, it writes a small program on the MBR started by the hard disk, this applet does not pass the file system, directly from the hard disk fan code, read the Kernel Image to load memory. In this way, the insurance factor is greatly increased. And also gave us the free use of the file system. So how do we install LILO?
First, we have to find an ordinary 800m IDE hard drive, connect on the IDE line of the target machine. In this way, on our target machine, Ide1 is hanging on the Flash disc, and Ide2 hangs a work hard disk. We use a standard step to install a debian GNU / Linux system on the Ide2 standard hard drive. Of course, if the reader friends don't have Debian, you can also install the Red Hat system. After installing the working system, you should first do some cut work, and remove unnecessary service and x windows, etc. The purpose of this is to enhance the system start speed, because we are in the back of work, it is definitely restarting the machine, so the start speed is critical to our work efficiency.
After installing the working system, do an EXT2 file system on the FALSH disk, which can be done with MKE2FS command. Since the Flash disc is connected to IDE1, it is in Linux, its identity is / dev / hda. This article divides the entire Flash disk throughout the entire partition when the author is operating, so when the mke2fs is called, the / dev / hda1 is processed. Readers' friends should be able to make an EXT2 file system directly on / dev / hda without having to partition in advance.
After doing a file system on the Flash disk, you can copy a compiled kernel image file VMLinuz on the Flash disk. Note that you must copy this VMLinuz image file to the Flash disk before you can install LILO on the Flash disc. Otherwise, Lilo will make Lililili to hit the buse, because it will not find the location of the kernel image on the Flash disk, then the Flash disk will not start. Also, if the reader friends use a compressed file system on the Flash disk, LILO will also have problems, although it can find the starting position of kernel Image on the hard disk, but it has no way. This kernel image is processed by the file system, and I don't know how to expand it into memory. After copying the kernel image, we can handle a lilo.conf file, this file can be placed on the working system. But pay attention to the path to the file name index in lilo.conf to write right. These pathnames are the path name that looks on the working system. For example, if the Flash disk mount is below / mnt directory, then in lilo.conf, the path name of VMLinuz is / MNT / VMLinuz. Pay attention to this, don't make a mistake. Otherwise, if you accidentally put the LILO of the working system, it is troublesome. Edit Lilo.conf, then run the lilo command, pay attention to tell it to use this new lilo.conf file, not to use /etc/lilo.conf.
After installing LILO, we can immediately restart and test it. First, in the BIOS, set to start starting from IDE1, if we see Lilo's prompt, you can see the message of kernel output after pressing Enter, which is a successful installation of LILO. Remember this method of operation, and later we update the kernel image on the flash disk, remember to update Lilo. That is to say, to re-run a lilo command.
Compile the kernel
After the test successfully LILO installation, we have begun to consider compiling a new core. Of course, to compile new kernels, we must first enter our work system. Here is two ways to enter the working system. Do not change the setting of the BIOS, but when seeing the LILO prompt, type Linux root = / dev / hdb1, the front Linux is an entry defined in lilo.conf, we only use this Entry specified Kernel Image, but use / dev / hdb1 as the root file system. Two ways may sometimes have a better than another, more convenient. This is to see the specific situation. However, their settings are not conflict with each other.
When compiling the kernel, because our kernel is only used by only one machine, we should have the situation of it. What you need is directly compiled into the kernel. The kernel described above is added to a normal 586 motherboard, and it is generally less than 800K bytes. Therefore, this approach is feasible. Moreover, the complexity of init scripts is reduced. Considering the operation, since the Kernel code required is to be loaded into memory, it does not cause waste of memory. On our target platform, we want to use a USB storage device. Another point to pay attention is to support the Frame Buffer. This is mainly to support xfree86. Generally speaking, if our graphics card is directly supported by Xfree86, it is of course best, and does not need Frame Buffer kernel support. But if Xfree86 does not support our graphics, we can consider using VESA mode. However, Xfree86's VESA card support is not very beautiful, and there is a security problem, sometimes the flower screen will appear when starting and exiting X WINDOW. So we can use the Kernel's VESA mode Frame Buffer and then use the XFree86's Linux Frame buffer driver. This generally does not see the phenomenon of the flower screen, and there is no problem in security.
DEVFS is also the topic we are interested in. If kernel does not use devfs, then the ROOT file system on the system has all the contents below the / dev directory. These contents can be built with / dev / makedev scripts or can be used by MKNOD. This method has its own benefits. But its disadvantages are troubles, and it is inconsistent with the state of Kernel. Conversely, if you use devfs, we don't have to worry about anything below the / dev directory. The item below / dev catalogs will have Kernel's code yourself. The actual effect is not obvious for the consumption of memory. So we chose DEVFS.
Busybox
After LILO and Kernel Image, then we have to arrange the root file system. Because the space of the Flash disk is only 16m bytes, it can be said that this is the biggest challenge to us. Here you first introduce you to a common tool when scheduled a ROOT file system: Busybox.
BusyBox is the famous Bruce Perens of Debian GNU / Linux First developed, in the installer in Debian. Later, there were many Debian Developers contributed to the power of Busybox, and the current maintainer Erik Andersen, he had cancer, but it was an excellent free software developer.
Busybox compiles a single independent executive, just called busybox. However, it can perform the functionality of the ASH shell according to the configuration, and dozens of various small applications. This includes a mini VI editor, an indispensable / sbin / init program, as well as other such as SED, IFCONFIG, HALT, REBOOT, MKDIR, MOUNT, LN, LS, ECHO, CAT ..., etc. It is essential for a normal system, but if we take the original of these programs, their volume is added together, let people can't eat. But busybox has all such versatics, the size is not 100K. Moreover, the user can decide to compile the functions of which applications in Busybox according to their own needs. In this case, the volume of BusyBox can be further reduced. It is also very simple to use Busybox. As long as you build a symbolic link, more ln -s / bin / busybox / bin / ls, then when executing / bin / ls, busybox performs the function of the LS, and processing the command line parameters in the way in the LS. Another example is ln -s / bin / busybox / sbin / init, so that we have an indispensable / sbin / init program for system operation. Of course, the premise here is that you compile the functionality of these two programs in Busybox.
One thing to note this is that the format of the / etc / inittab known in BusyBox is very simple, and the format of the conventional inittab file is different. Therefore, readers friends should pay attention to different syntax when writing inittabs for this busybox. As for the details, it is not said more here, please refer to BusyBox's user manual.
From start to enter the shell
After busybox is installed, we can consider restarting, until you enter the shell prompt. Before this, we have to prepare several important files under the / etc directory, and you have to copy the library of busybox.
With the LDD command, follow the path name of the binary program to be analyzed, you can know a binary, or a mutual dependency between a library file, such as BusyBox relies on libc.so and ld-linux.so, we With these knowledge, you can copy all the required library to the Flash disk. Since our Flash disk is big, it is not small, there are 16M bytes. We don't have much problem with Glibc's files. If the reader friends have special needs, I feel that Glibc is too large, I can consider using Uclibc, this is a very small libc library, of course, there is no GLIBC, but a embedded system is used. This article is no longer introduced to UCLIBC.
After the library is copied, we can consider the steps of the system startup. When startup, first LILO, next is KERNEL, KERNEL initialization, call / sbin / init, and then explain all kinds of all sorts of INITAS / ETC / ITTAB. INITTAB will guide init to call a most important system initializer /etc/init.d/rcs, we will complete MOUNT of each file system in RCS, in addition, there is also a DHCP program in RCS and put the network. After the RCS is completed, INIT will open a shell on a console, or open Getty login, so that the user will see the prompt to enter the username. In order to simply start, let's go directly to the shell, then wait until the debugging is successful, change it to the Direct access to X Window. About infittab grammar, we have already mentioned it, I hope readers and friends will check the authoritative busybox user manual. Here, we must first talk about the composition of the file system.
Arrange file system
Everyone has seen that our root file system uses the standard EXT2 file system in order to avoid trouble. Since our hard disk space is small, only 16m, and we have to put X Window on the top, so if we all use EXT2, the limited space of the Flash disc will be exhausted. Our only choice is to adopt an appropriate compressed file system. Considering the content below / usr directory, it is not necessary to be rewritten when the system is running. We decide to select read-only compressed file system Cramfs to accommodate all the contents below the / usr directory.
Cramfs is a small file system for Linus Torvalds I developed for embedded systems. Since it is read-only, although it takes ZLIB to compress, it can still be efficient random read. Since Cramfs does not affect the speed of the system read file, it is a highly compressed file system. For us, it is a quite good choice.
We first make all the contents of the / usr directory into a Cramfs image file. This can be done with the mkcramfs command. After getting this usr.img file, we have to consider how to make this image file Mount as an available file system when it is running in the system. Since this image file is not a common block device, we must use loopback devices to complete this task. Specifically, it is the front part of the /etc/init.d/rcs script mentioned earlier, plus a line mount command:
Mount -o loop -t cramfs /usr.img / usr
In this way, you can go up to the / usr directory of usr.img this cramfs in the / usr directory via the LoopBack device. Oh, yes, because of the use of loopback equipment, readers friends are compiling the kernel, don't forget to join the kernel's support for this device. For future operations, this MOUNT is transparent. The compression efficiency of Cramfs can generally reach nearly 50%, while most of our system is located below the / usr directory, so that it may be required to use 18m flash drive, now I can only need 11m . A 14m / usr directory, which is compressed into just 7m. The compression problem is considered. Here's below, the Flash disk is not like a normal hard disk, and the erasing of many times is not very good, so we consider, where you need to use multiple times, use memory. This task, we consider using TMPFS to complete. As for TMPFS and classic Ramdisk, we will not say more here. Generally speaking, TMPFS is more flexible, and the size of TMPFS is not like ramdisk, which can grow or narrow the user needs. We choose several directorys such as / TMP, / Var into TMPFS. This only needs us to add two lines similar to the following lines in / etc / fstab:
None / var TMPFS Default 0 0
Then don't forget to get close to the beginning of /etc/init.d/rcs, plus mount -a. In this way, all file systems specified in / etc / fstab can be moved up.
X window
Conducting here, readers may think that x window installation may be complicated. Actually, because we have a good shelf, X Window installation is very simple, just copy several key programs to come over. Generally speaking, only two BIN and LIBs below the / usr / x11r6 directory are required. Then, according to the respective needs of the user, it can also make a large clipping. For example, if you have an open XFS font server on your LAN, you can delete all local fonts and use the remote font server. If you only need to run a limited program, don't forget to delete the useless library. In addition, you can also delete excess X Window driver, only the driver you need to keep the local display card can be.
Of course, this is not allowed to do multiple tests.
Other tips
If your working system is on another machine, the SSH is a nice tool by the LAN and this unit. In addition, the SCPs in SSH are similar to those of ordinary CP copy programs, which is very convenient. Share files with SSH and SCP, remote test, you can run away in the office.
If you need a X Server and XFS font servers running on MS Windows, you can consider the XFree86 system included in the Red Hat Cygwin toolbox.
Reference
1. Busybox site:
http://www.busybox.net
2. Linux from scratch, do it yourself, start with a Linux system from scratch:
http://www.linuxfromscratch.org
3. Site: Uclibc:
http://www.uclibc.org
4. Site at Cygwin: http://www.cygwin.com
About author
Zhao Wei, freelancer. My network diary is located
http://www.advogato.org/person/zhaoway/. There are other articles I published on the network. Welcome readers and friends to believe and discuss issues.
Full text:
IBM DeveloperWorks China website
