1. Overview of root file system
1.1. Why do we need a root file system?
(1) The application of the init process is on the root file system
(2) The root directory of the kernel/provided by the root file system
(3) The application layer configuration (etc directory) after the kernel is started is on the root file system. It can almost be considered: distribution = kernel + rootfs
(4) The shell command program is on the root file system. Such as ls, cd and other commands
Summary: For a linux system, only the kernel itself cannot work. You must have configuration files in the etc directory on rootfs, shell commands in /bin/sbin and other directories, and library files in the /lib directory. ··) to work together.
1.2 What is the essence of the root file system
(1) The root file system is a special-purpose file system. No other file system can provide a root directory for the kernel, only the root file system can.
(2) The root file system must also belong to a certain file system format. rootfstype=
(3) What is the file system used for?
First of all, block devices (such as hard disks, flash, etc.) are divided into blocks (sectors). Physically, the bottom layer accesses the storage device according to the block number (sector number). This is very troublesome.
Secondly, the file system is some codes, a set of software. The function of this set of software is to manage the sectors of the storage device, and turn the access to these sectors into the access to directories and file names. When we access a file according to a specific directory and file name in the upper layer, the file system will convert this directory + file name into the corresponding sector number for access.
Finally, the difference between different file systems lies in the different management strategies and methods for these sectors, such as bad block management and fragment management.
2. The form of the root file system
2.1. Image file format
(1) An image file available for burning made by special tool software
(2) The image contains all files in the root file system (all files in the / directory)
(3) Burning this image is similar to formatting the corresponding partition.
(4) The image file system has a certain format, which is internalized and has nothing to do with the file name suffix.
2.2. Folder format
(1) The root file system is actually a folder containing specific content
(2) The root file system can be formed by adding necessary files to any empty folder
(3) The prototype of the root file system is in the form of a folder constructed in the development host
2.3. Summary
(1) The main purpose of the root file system in the form of an image file is to burn it to a block device, and mount it after the kernel on the device starts. The root file system in the form of an image file is made from the root file system in the form of a folder using a dedicated image creation tool.
(2) Initially create an empty folder with mkdir in the development host, and then add some necessary files to it (including runtime configuration files in the etc directory, executable programs in /bin and other directories, and /lib directory library files, etc.) to form a rootfs in the form of a folder. Then the rootfs in this folder form can be remotely mounted and used by the kernel through nfs, but it cannot be used to burn block devices. In order to burn this rootfs into the block device, we use some special software tools to make it into a root file system image in a certain format that can be burned.
(3) The rootfs in the form of a folder has no format. After making a mirror image, it will have a certain rootfs format. The format is determined by our image making process and tools. Each format of the image maker is used differently.
3. Make your own root file system in ext3 format
3.1 Introduction to mke2fs
(1) mke2fs is an application program, which is installed by default in ubuntu. This application is used to create root file systems in ext2, ext3, ext4 and other formats.
(2) Generally, the names of applications used to make rootfs in different formats are very similar, similar to mkfs.xxx (for example, the tool used to make rootfs in ext2 format is called mkfs.ext2, and the tool used to make rootfs in jffs2 format is called The tool is called mkfs.jffs2)
(3) mkfs.ext2 in ubuntu14.04 is just a symbolic link of mke2fs.
3.2. Manually make root file system in ext3 format
(1) Create rootfs.ext2 file and mount it to a directory for easy access
“References: http://blog.csdn.net/zhengmeifu/article/details/24174513”
dd if=/dev/zero of=rootfs.ext2 bs=1024 count=2048
losetup /dev/loop33 rootfs.ext2
mke2fs -m 0 /dev/loop33 2048
mkdir rootfs
mount -t ext2 /dev/loop33 ./rootfs/
(2) We create an ordinary empty file linuxrc in the image. This file will become /linuxrc in the image we made. After the kernel mounts this image, it will try to execute /linuxrc. Then it will fail when executed. The phenomenon seen in future experiments should be: the mount is successful, but the execution of /linuxrc fails.
(3) When actually making a useful rootfs in the future, it is necessary to add a real executable linuxrc program in this step, and then add other library files in the /lib directory, configuration files in the /etc directory, etc.
(4) Uninstall it, and then the image is ready.
umount /dev/loop33
losetup -d /dev/loop33
3.3. Rootfs.ext3 created by burning
4. Start the rootfs in the form of self-made simple folder in nfs mode
4.1, what is nfs
(1) NFS is a network communication protocol consisting of a server and a client.
(2) The role of nfs. Many direct applications can be made by using the nfs protocol. We use nfs here mainly for rootfs mounting. Run the kernel on the development board as the nfs client, and build the nfs server on the host ubuntu. Export the rootfs directory in the form of a folder we made in the nfs server of the host ubuntu, then you can mount the rootfs in the form of this folder in the client to start the system.
(3) Build an nfs server.
sudo apt-get install nfs-kernel-server sudo apt-get install nfs-common sudo vi /etc/exports Add /root/rootfs *(rw,sync,no_root_squash,no_subtree_check) at the end of the text Terminal execution chmod 777 -R /root/rootfs sudo exportfs -r update sudo showmount localhost -e terminal display Export list for 192.168.1.116 /root/rootfs* sudo /etc/init.d/nfs-kernel-server restart restart nfs service mount test mount -t nfs -o nolock localhost:/root/rootfs /opt After execution, enter the /opt directory. If you can see the content in /root/rootfs, it means that the nfs is successfully built!
4.2. Configure the kernel to support nfs as rootfs
(1) Set the bootargs of the nfs startup mode,
Found that the kernel is not configured to support nfs mode as the root file system boot
1. Configure the network part, mainly enable CONFIG_IP_PNP to see the Root file system on NFS option in 2 Networking support Networking options TCP/IP networking IP: kernel level autoconfiguration [*] IP: DHCP support [*] IP: BOOTP support \t\t\t\t\t 2. Configure and enable nfs service File systems ---> Network File Systems ---> <*> NFS client support [*] NFS client support for NFS version 3 [*] NFS client support for the NFSv3 ACL protocol extension [*] NFS client support for NFS version 4 (EXPERIMENTAL) [*] NFS client support for NFSv4.1 (DEVELOPER ONLY) [*] Root file system on NFS \t\t\t\t\t 3. Set the following startup parameters in uboot (IP changes according to actual use) setenv bootargs root=/dev/nfs nfsroot=192.168.1.30:/root/porting_x210/rootfs/rootfs ip=192.168.1.20:192.168.1.30:192.168.1.1:255.255.255.0::ens33:off init=/linuxrc console=ttySAC2,115200
(2) Configure support for nfs startup mode in menuconfig
There is still an error later, refer to the blog post https://blog.csdn.net/weixin_56646002/article/details/127388021?spm=1001.2014.3001.5506
4.3. Summary
(1) Starting in nfs mode is equivalent to remotely mounting the kernel on the development board to the rootfs on the host
(2) The nfs method does not need to make a rootfs image
(3) The nfs method is not suitable for real products, and is generally used for debugging in the product development stage
5. What is linuxrc?
5.1, /linuxrc is an executable application
(1) /linuxrc belongs to the application layer and has nothing to do with the kernel source code
(2) /linuxrc is executable under the current kernel system of the development board. Therefore, under the linux system of ARM SoC, this application program is compiled and linked with arm-linux-gcc; if it is under the PC linux system, then this program is compiled and linked with gcc.
(3) If /linuxrc is statically compiled and linked, it can run directly; if it is dynamically compiled and linked, we must also provide him with the necessary library files to run. But because our /linuxrc program is directly invoked and executed by the kernel, the user has no chance to export the path of the library file, so in fact this /linuxrc cannot be dynamically linked, and is generally statically linked.
5.2. When /linuxrc is executed, it leads to the user interface
(1) After the operating system is started, after a series of self-run configurations, it will eventually give the user an operation interface (maybe cmdline, maybe GUI), and this user interface is brought out by /linuxrc.
(2) Many things such as the user interface are not in charge of the /linuxrc program. The user interface has its own special application program, but the application program of the user interface is directly or indirectly called and executed by /linuxrc. The user interface program and other applications are processes 2, 3, 4… This is what we call process 1 (the init process, that is, /linuxrc) is the ancestor process of all other application processes.
5.3, /linuxrc is responsible for the configuration after the system starts
(1) It’s like a house that cannot be directly lived in after it is built, but needs to be decorated; the operating system cannot be used directly after it is started, but must be configured.
(2) The configuration of the application layer after the operating system is started (generally called runtime configuration, English abbreviation etc) is to make our operating system more convenient to use, more suitable for my personal hobbies or practicality.
5.4, /linuxrc is generally busybox in embedded linux
(1) busybox is a project written in C language, which contains many .c files and .h files. This project can be configured and compiled into applications that can run on various platforms. If we use arm-linux-gcc to compile busybox, we will get an application that can run on the linux kernel of our development board.
(2) The program busybox was developed to build rootfs in an embedded environment, that is to say, it is a specially developed init process application.
(3) busybox provides a complete set of shell command assemblies for the current system. For example, vi, cd, mkdir, ls, etc. In the desktop version of Linux distributions (such as ubuntu, redhat, centOS, etc.), vi, cd, ls, etc. are all separate applications. But in embedded linux, in order to save trouble, we gather all commonly used shell commands such as vi and cd together to form a shell command package, named busybox.
6. What else should be in rootfs
6.1. The most important thing is /linuxrc
bin, sbin: applications, the shell command set under bin, and some application programs used by the system under sbin, which must be
cdrom: mount cd, not necessary
home: the root directory of ordinary users, not required
lost + found: recycle bin, optional
opt: Miscellaneous directory, you can put anything in it, not necessary
root: the root directory of the root user, not required
tmp, mnt: same as opt, dispensable
board: related to the board, not required
dev: The device files are placed under the dev directory, which must be
media: used to mount multimedia-related, not necessary
srv, output, run, boot: not required
sys, pro: cannot be omitted
usr: It is full of user-related things, must
etc: very important, must
lib: The lib directory contains the dynamic and static link library files in the current operating system, which cannot be omitted
6.2. Device files in the dev directory. In linux, everything is a file, so a hardware device is also virtualized into a device file to access. In the linux system, /dev/xxx represents a hardware device. When we want to operate this hardware, we need to open the device file, and then read/write/ioctl operate the device, and finally close closes the device.
The /dev directory is also indispensable in the smallest rootfs, and there are one or two device files that are necessary for rootfs.
6.3, sys and proc directories. It is also indispensable in the smallest rootfs, but these two only need to create an empty folder, there is nothing in it, and there is no need to have anything. These two directories are also related to the driver. It belongs to the virtual file system in linux.
6.4. usr is the storage place for some files owned by system users, which will be automatically generated when busybox is installed in the future.
6.5. The etc directory is a very critical and important one. All files in the directory are runtime configuration files. All configuration files in the /etc directory will be directly or indirectly invoked and executed by /linuxrc to complete the runtime configuration of the operating system. The etc directory is the key to making rootfs.
6.6. The lib directory is also a very critical one in rootfs and cannot be omitted. The lib directory contains the dynamic and static link library files in the current operating system. We are mainly for the dynamic link library.
7. Introduction to VFS
7.1. What is VFS
(1) VFS is a design concept and design mechanism of the Linux kernel. VFS is vitrual file system, called virtual file system.
(2) Some specific file systems such as FAT, NTFS, ext2, ext3, jffs2, yaffs2, ubi, etc. are mainly designed to manage block devices (hard disk, Nand…)
(3) VFS draws on the design concept of the file system (through the file system to convert the hard-to-manage physical disk sector access at the bottom layer into a directory + file name to access), and virtualizes the access of hardware devices to Directory + file access. So with VFS, we can access the hardware devices in the system through the device file (directory + file name, such as /dev/mmcblk0p2).
(4) From the above, we can initially see some of the power of VFS, but VFS is more than that.
7.2. Significance of VFS
(1) The access to hardware devices mentioned above unifies the access to hardware devices and the access to ordinary files to the interface (everything in linux is a file).
(2) The access details of the upper layer of the operating system (application layer) to different file system types of the lower layer are shielded. Therefore, if there is no VFS, when we write the cp command (the same is true for other commands), we have to consider what file system type your cp file is in. So the cp command is very complicated, so the specific file system type should be considered. With VFS, the situation is different. VFS has become an isolation layer, which isolates the differences of different file systems in the lower layer and provides a unified interface for upper-layer applications.
(3) Different types of file systems do not need to consider the specific operation differences of various hardware devices when designing themselves. Here is a design concept similar to VFS.
7.3, the relationship between VFS and our study
(1) The VFS mechanism and rootfs mount are related to the mount of other file systems.
(2) There are some virtual file systems such as sys proc in the kernel, which are also related to the VFS mechanism.
(3) The device files in the /dev/ directory are all related to VFS, so learning the driver cannot bypass VFS.