linux
This article will guide you to build a mini – Linux system. It takes up much lesser than 16M bytes of hard disk space, but does include the XFree86’s, X Window System.
.
.
.
Target: mini Linux System
This should build this mini-Linux system for only one particular single run, if the reader friends who are interested in this system to be improved on the basis, they can build a generic one,that can run in most conventional PC, with plug and play systems . But this has not explained within the topic of this article my reader friends.
Our target Linux system runs on an ordinary Intel 386 PC machine, for which, you can have the hard disk,but you can not use that drive, but we will use the Flash Disk instead. If using Flash disk, then, that system needs to be able to support boot from Flash disk,and that Flash disk size should be 16M bytes or more. We want the user to do a start-up, directly into the X Window graphical interface, run a good program specified in advance. As it does not require the user to enter a user name and password to log in.
We set this goal a bit like an X Terminal terminal workstations. Little improvement, can also be made in the form of diskless, where altogether, even the Flash disk of 16Mb is also do not required. However, this is also beyond the topic of this article.
.
.
.
System Startup
.
Because we have to consider from Flash disk to start, so we chose to use our LILO Boot Loader, instead of using the GRUB. As we have given to the GRUB on the hard drive and has a strong ability to identify the file system, and Flash is not a standard hard disk in the end. So when we use the file system, GRUB does not necessarily know, they might be self-defeating the GRUB counter. The LILO is much simpler, and it is written in the MBR of the hard disk.This starts a small program, this small program does not pass through the file system directly from the hard disk sector number, they readout Kernel Image into memory. Thus, the safety factor is greatly increased. And also gave us the way to choose the file system. So, how do we install LILO in it?
First of all, we are looking for an ordinary IDE hard disk 800M or so, even when we have the target machine’s IDE online. So our target machine, IDE1 hang the Flash disk, IDE2 is a work hard to hang. We use the standard procedure in a standard hard drive installed on IDE2, a Debian GNU / Linux system. Of course, if readers and friends, you do not have Debian, Red Hat systems can also be installed. Operating system installed after the job, cuts would be the first to do something, to remove unnecessary Service and the X Window, so few things are deleted. The aim is to improve system boot speed, because when we work in the back, it must constantly restart the machine, so the startup speed of our work efficiency is critical.
After working system installed on the disk to make a Falsh Ext2 file system, the use of mke2fs command can be completed. Since Flash drive is connected on to the IDE1, so inside the Linux, its identity is /dev/hda. The author, when in operation,will use the entire Flash disk partition for dividing a whole, therefore, call mke2fs when the treatment is /dev/hda1. Readers should be directly using the /dev/hda to do an Ext2 file system without prior partition.
When done with the Flash file system on the disk, you can put an image file compiled kernel of vmlinuz, copied to the Flash disk. Note that you must first have the vmlinuz image file copied to the Flash disk, before you can install LILO. Otherwise, LILO will waste time, because it will not find Kernel Image in Flash disk position, so the Flash disk will not start up. Also, if readers and friends will use the Flash disk using a compressed file system, then, at the time LILO will go wrong, although it is able to find the right Kernel Image starting location on the hard drive, but there is no way, to be processed by the file system to re-compressed the Kernel Image,as we do not know how to expand it into memory. After the Kernel Image copy the past, we can begin to edit a lilo.conf file, this file can be placed on the line on a working system. But note that in the lilo.conf file name in the path of the index can be easily written. These path names are in the working path name, appears on the system. For example, if the Flash disk Mount in /mnt directory, then, in lilo.conf, vmlinuz pathname is /mnt/vmlinuz. Note that this is no mistake. Otherwise, if you accidentally put LILO working system to destroy it, then you will be in trouble. Edit Well lilo.conf, then run lilo command attention, to tell it to use this new lilo.conf file, rather than using /etc/lilo.conf.
When LILO is installed, we can immediately restart test. First, in the BIOS, set from IDE1 started, if we see the LILO prompt, press Enter after when you can see Kernel output, which is regarded as the LILO installation was successful. Remember this method of operation, after each time we update the Flash disk on Kernel Image, remember to update LILO. That is, to re-run lilo command again.
.
.
.
Compile the Kernel
.
Successfully tested after installation of LILO, we began to consider compiling a new kernel. Of course, when you want to compile a new kernel, we must first enter our working system. There are two ways to enter the work system, first in the BIOS boot settings from IDE2, of course, which requires the original installation of the system, put LILO installed in / dev / hdb on; Another approach is to start or from the IDE1 without changing the BIOS settings, but after seeing the LILO prompt when you want to type linux root = /dev/hdb1, linux is defined inside a lilo.conf entry, we use only the entry specified by the Kernel Image, but using / dev/hdb1 as the root file system. In this two approaches,sometimes one is better than another, more convenient. That depends on the specific situation. However, they are not conflicting settings.
In compiling the kernel, because our core is only for one machine to use, so we should be well aware of its situation; On the other hand, in order to reduce unnecessary complexity, we decided not to use kernel module support, and all need something compiled directly into the kernel inside. Such a kernel compiled in an ordinary 586 motherboard, put all the necessary features are added, generally not to 800K bytes. Therefore, this approach is feasible. And reduce the complexity of the init scripts. From the operational aspects to consider, anyway, due to the need of the kernel code is to be loaded into memory, and hence does not cause memory waste.
In our target platform, we want to use a USB storage device. Another point to note is that on the Frame buffer support. This is mainly to support XFree86. Generally speaking, if our graphics are directly supported by XFree86, then of course for the best, there is no frame buffer kernel support. But if we do not support XFree86 graphics, we can consider using VESA mode. But the XFree86 VESA card support up and running very beautiful, there are security issues, sometimes in the startup and exit X Window will appear when the video. So we can use the kernel vesa mode frame buffer, and then use the xfree86 the linux frame buffer driver. So generally do not see Huaping phenomenon, but also a safe without any problem., evfs is our topic of interest. If the kernel does not use devfs, then the root file system on the system must have the / dev directory all of the following content. These contents can be used / dev / MAKEDEV script to create, you can also use mknod manually one by one to build. This method has its own advantages. But its drawback is troublesome, but the state of the kernel and not consistent. Conversely, if you use devfs, we no longer have to worry about the / dev directory any of the following things. / Dev directory items below will be responsible for their own kernel code. The effect of the actual use, the memory consumption is not obvious. So we choose devfs.
.
.
.
Busybox
.
With LILO and the kernel image, the next step, we have to arrange the root file system. Since flash disk space is only 16M bytes, you can say that this is our greatest challenge. First of all here would like to introduce arrangements for small embedded Linux system, root file system,with a common weapon: BusyBox. Busybox is Debian GNU / Linux. It is famous as Bruce Perens, first developed it using the Debian installer. Later, there are many Debian developers contribute, in particular, which is currently pushing busybox maintainer Erik Andersen, as he was suffering from cancer, but he is an excellent free software developer. Busybox compile a single, independent enforcement procedures, called busybox. But it can be depending on the configuration, perform the ash shell functions, as well as dozens of various small application functionality. This includes a mini vi editor, integral to the system / sbin / init program, as well as others, such as sed, ifconfig, halt, reboot, mkdir, mount, ln, ls, echo, cat … so these are essential for a normal system, but if we put these programs originals take over the case, their volume together, too much for people. But there are all busybox so versatile, but also the size of about 100K. Moreover, users can also use them according to their own needs, determine in the end to which several of busybox compiled into the application’s functionality. In this case, busybox volume can be further reduced. Busybox is also very simple to use. Just build a symbolic link, for example, ln-s / bin / busybox / bin / ls, then execute / bin / ls time, busybox ls will execute the function, also handled in accordance with the ls command line parameters. Another example ln-s / bin / busybox / sbin / init, so that we have a system running an indispensable / sbin / init program. Of course, the premise here is that you go in busybox, and compile the function of these two programs.
From start to enter the shell,busybox installed, we can consider re-start until we are well into the shell prompt. Prior to this, we have to prepare /etc directory of several important documents, and make use of the library that busybox also copied.
Use ldd command, followed by the binary program to analyze the path name, you can know a binary program, or a library interdependencies between files, such as busybox will depend on libc.so and ld-linux.so, we With this knowledge, you can put all the necessary hands-library copy to flash disk. We will use Glibc files directly without much problem. If readers have any special needs, and feels Glibc too large, then you can consider using uClibc, this is a very small libc library function, but enough to use an embedded system. This article is no longer describes the uClibc.
Library program copied later, we can consider the system startup procedure. Start time, first lilo, the next step is kernel, kernel initialization, you call the / sbin / init, then interpreted by the init / etc / inittab to run all sorts of things. inittab will instruct init to invoke one of the most important system initialization program / etc / init.d / rcS, we will all be completed in rcS file system mount, in addition, there are procedures in rcS dhcp call, the network rack up. rcS execution is over, init will be in a console, in accordance with the instructions inittab open a shell, or open getty + login, so the user will be prompted to enter a user name prompt. We are here for the sake of simplicity, the first directly into shell, and wait until after the successful commissioning, and then changed directly into X Window.
About inittab grammar, we already mentioned, I hope readers and friends to check the authority of busybox user manual. Here, we need to talk about the composition of the file system.
.
.
.
Arrangements File System
.
We have seen that our root file system in order to avoid trouble, using a standard ext2 file system. Because of our hard drive space is very small, less than 16M, but we have placed in the top X Window, so if we all use ext2 words, Flash disk limited space will soon be exhausted. Our only option is to use a proper compressed file system. Taking into account the / usr directory run the following elements in the system when it is not need to be rewritten. We decided to choose a compressed read-only file system cramfs to accommodate the / usr directory below in its entirety. cramfs is Linus Torvalds, which had developed a system for small embedded file system. Since it is read-only, so, although it did take a zlib compression, but it still can be done efficient random reads. Since cramfs read the file,and does not affect the speed of the system, but it is also a highly compressed file system, for us, so it is a pretty good choice.
We first put the / usr directory and the entire contents of the image files into a cramfs. This can let mkcramfs command to complete. Got this usr.img file, we need to consider how the system is running, put the image file mount up and become a usable file system. Due to this image file is not a block device in the usual sense, we must use loopback devices to accomplish this task. Specifically, that is, in the aforementioned / etc / init.d / rcS script , together with the mount command line:
mount-o loop-t cramfs / usr.img / usr
Thus, via loopback device, put usr.img this cramfs the image files to mount the / usr directory go up. Oh, right, because to use loopback device, readers and friends, when compiling the kernel, do not forget to add kernel support for this device. The operation of the system in the future, this effect of the mount is transparent. cramfs general compression efficiency can reach nearly 50%, while the vast majority of our system on the contents of the / usr directory, this way, the original might want to use the Flash disk 18M, 11M now may only need to be used for a 14M / usr directory, to compress into just 7M.
Compression problem considered above, the following also take into account, Flash disk after all, unlike ordinary hard drive, erase many times not so good after all, so we consider the need to repeatedly rewritable place, the use of memory to do. This task, we consider the use of tmpfs to complete. As for the ramdisk tmpfs and classic comparison, we do not say here. Generally, tmpfs more flexible, tmpfs size unlike ramdisk, you can follow the user’s need to grow or shrink. We chose to / tmp, / var, and several other directories make tmpfs.
We only need to / etc / fstab inside with two lines similar to the following text on it:
none / var tmpfs default 0 0
Then do not forget the / etc / init.d / rcS inside the place near the beginning, with mount-a. In this way, you can put / etc / fstab inside the specified mount,when all file systems are coming up.
.
.
.
X Window
.
Conducted here, readers and friends may think, X Window installation may be very complicated. In actual fact, because of our setting up the top shelf, X Window installation is very simple, just need a few key programs can be copied. Generally speaking, you only need / usr/X11R6 directory below the bin and lib two directories. Then, according to their needs user, you can also make substantial reductions. For example, if your LAN has an open xfs font server, you can put all the fonts are deleted locally, while using a remote font server. If you only need to run a limited program, do not forget that useless library are deleted. In addition, you can put the extra X Window’s driver, and when it can be deleted, leaving only the unit’s display card driver needed by it.
Of course, this will inevitably have to do several tests off.
Other tips If you work the system type in another machine, the machine via LAN and Internet, then, ssh is a good tool. In addition, ssh scp in bands with them and ordinary cp copy program almost, very convenient.If you need to run on an MS Windows X Server and xfs font server, consider including Red Hat’s Cygwin toolbox XFree86 system.
.
.
.
Reference Material
.
BusyBox site: http://www.busybox.net
Linux From Scratch, do it yourself, do a Linux system from scratch: http://www.linuxfromscratch.org
