1, Introduction to file system
File system: it is the method and data structure used by the operating system to specify the files on the disk or partition, that is, the method of organizing files on the disk. Linux file system is a complete unity, organized into a tree directory structure.
Linux follows the file system scientific classification standard (FHS), a standard that defines the names and locations of many files and directories.
The main rules are as follows:
The configuration file is placed in the / etc directory
The device files are placed in the / dev directory
The library files are placed in the directory / lib
The directories where the compiled executable files and commands are stored are / bin, / sbin, / usr/bin, / usr/sbin directories
In embedded systems, many directories under the root directory can be deleted, as follows:
All directories that provide an extensible environment for multiple users should be deleted; For example, (/ home,/mnt,/root)
The / boot directory can be deleted according to the boot loading.
Other directories
/bin,/dev,/etc,/proc,/sbin,/usr,/lib are indispensable.
2, BusyBox introduction
From the name, Busybox is a "busy box". In fact, Busybox can be understood as a collection of Linux commands. The common commands we need for Linux operation can be found in Busybox, but Busybox does not simply collect all commands together. It adopts a very clever way, that is Use one program to do everything.
Usually, when we use ls, vi and other commands, we need to use glibc related calls. Therefore, if each command statically links these calls, each command will be very large. Therefore, glibc will be dynamically linked in the usual distribution version, but the dynamic library of glibc itself is very large, which is acceptable in PC + Linux, but in embedded systems, it is too large and complex Not all library functions are used.
Generally, there are two solutions: one is to cut glibc, and the other is Busybox, that is, change the name of the main function of ls, vi and other programs, link them all together, and then statically link glibc. In this way, only the required calls will be linked, and the whole Busybox program may be smaller than the dynamic library of glibc.
Therefore, the working principle of busybox is to determine which program the user wants to call according to the file name. For example, if the file name of your busybox program is ls, LS is running and vi is running.
Here are the steps for cross compiling and using Busybox-1.00 on arm linux platform:
Copy the file busybox-1.00.tar.gz to the Linux directory, and execute the following command to unzip the file:
#tar xzvf AT91RM9200-busybox-1.00.tar.gz
When the file is decompressed, it will be generated automatically busybox-1.00 Directory, enter the directory, and execute the following command to compile:
#make clean; clear old compiled files #make menuconfig modify some necessary options here #make ARCH=arm CROSS_COMPILE=arm-linux- CONFIG_PREFIX=/root/build_rootfs/rootfs all install
Busybox is a software that integrates more than 100 most commonly used linux commands and tools. It even integrates an http server and a telnet server, but all these functions are only about 1M in size. The Linux commands we usually use are like component electronic components, and busybox is like an integrated circuit that integrates common tools and commands Shrunk in an executable file, the function is basically unchanged, but the size is many times smaller. Busybox is widely used in embedded Linux applications.
The programs provided by Busybox include:
With shell functions, such as csh
Provide a mini vi editor
Provide the / sbin/init program indispensable to the system
Other basic system commands, such as ls, mkdir, ifconfig, etc.
III. Linux file system construction steps
3.1.1 download busybox
Can from http://busybox.net/downloads/ Download busybox source code.
3.1.2 decompression source code
$ tar xvf busybox-1.22.1.tar.bz2 $ cd busybox-1.22.1
3.1.3 configuring busybox source code
$ make menuconfig
Busybox Settings —>
Build Options —>
[*] Build BusyBox as a static binary (no shared libs)
[ ] Force NOMMU build
[ ] Build with Large File Support (for accessing files > 2 GB)
(arm-none-linux-gnueabi-) Cross Compiler prefix
() Additional CFLAGS
3.1.4 compiling source code
$ make
3.1.5 installing the root file system
The default installation path of busybox is _installunder the source directory
$ make install
Enter the installation directory:
$ cd _install $ ls
bin linuxrc sbin usr
Create other required directories:
$ mkdir dev etc mnt proc var tmp sys root
Add library:
Copy the libraries in the tool chain to the _install directory:
$ cp /home/linux/gcc-4.6.4/arm-arm1176jzfssf-linux-gnueabi/lib/ ./_install/ -a
Delete symbol tables in static and shared library files:
$ sudo rm lib/*.a # Arm none Linux gnueabi strip lib / *. So (execute command under super user)
Delete unnecessary libraries and ensure that the size of all libraries does not exceed 4M:
$ du -mh lib/
Add system startup file:
Add the file inittab under etc. the contents of the file are as follows:
#this is run first except when booting in single-user mode. ::sysinit:/etc/init.d/rcS # /bin/sh invocations on selected ttys # start an "askfirst" shell on the console (whatever that may be) ::askfirst:-/bin/sh # stuff to do when restarting the init process ::restart:/sbin/init # stuff to do before rebooting ::ctrlaltdel:/sbin/reboot
Add the file fstab under etc. the contents of the file are as follows:
#device mount-point type options dump fsck order proc /proc proc defaults 0 0 tmpfs /tmp tmpfs defaults 0 0 sysfs /sys sysfs defaults 0 0 tmpfs /dev tmpfs defaults 0 0
The file system we mount here has three proc, sysfs and tmpfs. In the kernel, both proc and sysfs are supported by default, while tmpfs is supported
There is no support. We need to add tmpfs support
Modify Linux kernel configuration;
$ cd ~/ kernel/linux-3.14 $ make menuconfig
File systems —>
Pseudo filesystems —>
[] Virtual memory file system support (former shm fs)
[] Tmpfs POSIX Access Control Lists
Recompile kernel:
$ make uImage $ cp arch/arm/boot/uImage /tftpboot
Go back to the created file system, create the init.d directory under etc, and create the rcS file under init.d. the content of the rcS file is:
#!/bin/sh # This is the first script called by init process /bin/mount -a echo /sbin/mdev > /proc/sys/kernel/hotplug /sbin/mdev -s by rcS Add executable permissions: $ chmod +x init.d/rcS
Add a profile file under etc. the file content is:
#!/bin/sh export HOSTNAME=Exynos4412 export USER=root export HOME=/root export PS1="[$USER@$HOSTNAME \W]\# " PATH=/bin:/sbin:/usr/bin:/usr/sbin LD_LIBRARY_PATH=/lib:/usr/lib:$LD_LIBRARY_PATH export PATH LD_LIBRARY_PATH
Important: if the newly created file system size exceeds 8M, delete unnecessary library files
3.2 NFS test
3.2.1 copy the new root file system to the / source/rootfs directory
$sudo mkdir /opt/rootfs $sudo cp _install/* /opt/rootfs –a
3.2.2 setting uboot parameters
#setenv bootargs noinitrd root=/dev/nfs nfsroot=192.168.13.116:/opt/rootfs init=/linuxrc console=ttySAC2,115200 ip=192.168.13.123
3.2.3 experimental phenomena
Nfs root file system mounted successfully
3.3 ramdisk file system production experiment
3.3.1 create an image file with a size of 8M
$ cd ~ $ dd if=/dev/zero of=ramdisk bs=1k count=8192 ( ramdisk For 8 M)
3.3.2 format the image file as ext2
$ mkfs.ext2 -F ramdisk
3.3.3 create the initrd directory under mount as the mount point
$ sudo mkdir /mnt/initrd
3.3.4 mount the disk image file to / mnt/initrd
Note that the ramsidk here cannot be stored in the rootfs directory
$ sudo mount -t ext2 -o loop ramdisk /mnt/initrd
3.3.5 copy our file system to initrd.img
Copy all the contents of the tested file system to the / mnt/initrd directory
$ sudo cp /source/rootfs/* /mnt/initrd –a
3.3.6 uninstall initrd
$ sudo umount /mnt/initrd
3.3.7 compress initrd.img to initrd.img.gz and copy it to / tftpboot
$ gzip --best -c ramdisk > ramdisk.gz
3.3.8 format as uboot Recognized Format
$ mkimage -n "ramdisk" -A arm -O linux -T ramdisk -C gzip -d ramdisk.gz ramdisk.img $ cp ramdisk.img /tftpboot
3.3.9 configuring the kernel to support RAMDISK
After making ramdisk.img, you need to configure the kernel to support RAMDISK as the boot file system and modify the kernel configuration
$ make menuconfig
File systems —>
<> Second extended fs support
Device Drivers
SCSI device support —>
<> SCSI disk support
Block devices —>
<>RAM block device support
(16)Default number of RAM disks
(8192) Default RAM disk size (kbytes) (modified to 8M)
General setup —>
[] Initial RAM filesystem and RAM disk (initramfs/initrd) support
3.3.10 recompile kernel
Copy to uImage / tftpboot directory
$cp arch/arm/boot/uImage /tftpboot
3.3.11 reset uboot startup parameters:
# setenv bootcmd tftp 41000000 uImage\;tftp 42000000 exynos4412-etc4412.dtb\; tftp 43000000 ramdisk.img\; bootm 41000000 43000000 42000000 # saveenv
IV. file system mount
pc settings
Mount NFS
apt-get install nfs-kernel-server
Configure NFS
# gedit /etc/exports
Replace with the following:
# /etc/exports: the access control list for filesystems which may be exported # to NFS clients. See exports(5). # # Example for NFSv2 and NFSv3: # /srv/homes hostname1(rw,sync,no_subtree_check) hostname2(ro,sync,no_subtree_check) # # Example for NFSv4: # /srv/nfs4 gss/krb5i(rw,sync,fsid=0,crossmnt,no_subtree_check) # /srv/nfs4/homes gss/krb5i(rw,sync,no_subtree_check) # /opt/rootfs *(rw,sync,no_root_squash)
Restart NFS service
# /etc/init.d/nfs-kernel-server restart
[ ok ] Starting nfs-kernel-server (via systemctl): nfs-kernel-server.service
test
# showmount -e Export list for ubuntu: /opt/fs/rootfs/rootfs *
Setting of development board
etc4412# setenv bootargs noinitrd root=/dev/nfs nfsroot=192.168.13.79:/opt/rootfs/ rw init=/linuxrc console=ttySAC2,115200 ip=192.168.13.100 etc4412# saveenv
noinitrd: must be configured, otherwise it will still enter the memory file system.