NFS file system of Linux virtual machine on the Development Board
Http://apps.hi.baidu.com/share/detail/48189956
Today, I did an experiment on embedded applications.
How can I run cross-compiled applications on your host on an embedded system?
Here I chose to mount the NFS file system over a network.
My lab environment:
The host machine is a virtual machine centos5.4
The target machine is Linux on mini2440.
Here I use a crossover network cable to connect
1. Install the NFS server on a virtual machine
(1) install the following two files:
# Rpm-IVH nfs-utils-1.0.1-2.9.i386.rpm portmap-4.0-54.i386.rpm
The Portmap monitoring program only directs the RPC communication data stream so that the NFS client can find the directory shared by the NFS server.
(2) Configure NFS and set the output shared directory
[Root @ localhost MNT] # vi/etc/exports
Here I just set it up.
/Home/share * (RW, sync)
Then, the configuration file takes effect.
[Root @ localhost MNT] # exportfs-RV
Exporting *:/home/share
Start NFS
[Root @ localhost MNT] #/etc/init. d/Portmap restart
Stop Portmap: [OK]
Start Portmap: [OK]
[Root @ localhost MNT] #/etc/init. d/nfs restart
Disable NFS mountd: [OK]
Disable the NFS daemon: [OK]
Disable NFS quotas: [OK]
Disable NFS: [OK]
Start the NFS service: [OK]
Disable NFS quota: [OK]
Start the NFS daemon: [OK]
Start NFS mountd: [OK]
[Root @ localhost MNT] #
Note that the Starting sequence cannot be messy. Start Portmap first and then start NFS.
2. Connect the virtual machine to the Development Board
1. Set the network mode of the virtual machine to bridge with the Local Machine
2. Cross-network cable used for connection between the Development Board and the Local Machine
3. Set the network of the Local Machine, virtual machine, and Development Board to the same network segment.
Here I set
Local Machine: 10.6.173.small
Virtual Machine: 10.6.173.225
Development Board: 10.6.173.226
Ping, you can pass. Well, the success is beckoning to you.
3. Connect the development board from the Super Terminal and mount the NFS file system:
# Mount-O nolock, RW-t nfs 10.6.173.225:/home/share/mnt/nfs
Parameter to be added:-O nolock (I didn't add it at the beginning, so I couldn't mount it, And I always prompted a timeout)
Then, I found some information online:
The following is a summary of others:
Source: http://tensing.blog.sohu.com/77399040.htm
1. Establish an NFS development environment
The NFS development environment for Embedded Linux includes two aspects: NFS server support for Linux server and NFS client support for target board.
1.1 Linux Server
1.1.1 Log On As root, compile the exports configuration file of the shared directory, and specify the shared directory and its permissions.
# Vi/etc/exports
Add:
/Home/lqm (shared directory) 192.168.1. * (RW, sync, no_root_squash)
The added content allows the computer with the IP address range of 192.168.1. * to access the shared directory/home/lqm with the read and write permissions.
[Note: The parameters are described as follows:
RW --- read/write permissions. If read-only permission is set, it is set to ro. But in general, to facilitate interaction, you must set it to RW.
Sync-synchronize data into memory and hard disk.
No_root_squash -- this parameter is used to require the server to allow remote systems to access this directory with its own root privilege. That is to say, if the user is root, then he has the root permission on the shared directory. Obviously, this parameter grants great rights to the target board. Security is the first thing to consider. You can adopt a certain protection mechanism. The following describes the protection mechanism. If the default root_squash is used, many of the Target Board's own root file systems may not be able to write data, so the running will be greatly restricted. We recommend that you use the no_root_squash parameter while ensuring security .]
1.1.2 initial Protection Mechanism
You can set the/etc/hosts. Deny and/etc/hosts. allow files to restrict the access permissions of network services.
* **/Etc/hosts. Deny ***
Portmap: All
Lockd: All
MOUNTD: All
Rquotad: All
STATD: All
* **/Etc/hosts. Allow ***
Portmap: 192.168.1.100
Lockd: 192.168.1.100
MOUNTD: 192.168.1.100
Rquotad: 192.168.1.100
STATD: 192.168.1.100
By using these two files at the same time, only machines with IP address 192.168.1.100 can use the NFS service. Set the IP address of your target board to 192.168.1.100.
1.1.3 start
First, start the portmapper (Port ing) service, which is required by NFS itself.
#/Etc/init. d/Portmap start
Then start the NFS server. In this case, NFS activates the daemon and starts to listen to client requests.
#/Etc/init. d/nfs start
After the NFS server is started, check the Linux server's iptables and so on to make sure that the port used by NFS is not blocked and the host that allows communication.
You can perform the NFS recycle test on the Linux server first. Modify/etc/hosts. Allow, change the IP address to the IP address of the Linux server, and then run the following command on the Linux Server:
# Mount-t nfs <your-server-ip>:/home/lqm/mnt
# Ls/mnt
If the NFS server works properly, you should see the contents of the shared directory/home/lqm under/MNT.
1.2 target board Client
1.2.1 The embedded Linux kernel should support the NFS client.
When configuring the kernel, select the following:
File System --> network file systems -->
Select NFS system support and provide nfsvs client support, save and exit, re-compile the kernel, and re-download the generated zimage to the target board.
1.2.2 in the Linux Shell of the target board, run the following command to mount the NFS shared directory.
# Mkdir/mnt/nfs
# Mount-O nolock-t nfs <your-server-ip>:/home/lqm/mnt/nfs
# Ls/mnt/nfs
Because Portmap is not included in the root file system of many embedded devices, the-O nolock parameter is generally used, that is, the NFS file lock is not used, so that Portmap can be avoided. If it succeeds, you can see the content in the shared folder of Linux Server under/mnt/NFS, and the modifications in the two folders are synchronized.
2. Application Instance
Write a simple C program test. c
-------------------------------------------
/* This is a test program .*/
Int main (void)
{
Int I;
For (I = 0; I <10; I ++)
Printf ("Hello world % d times. \ n", I );
Return 0;
}
-------------------------------------------
Compile the program:
# Arm-Linux-gcc-O test. c
2.1 FTP
First download test to target board. Start Linux on the target board and run the following command on the Super Terminal:
# Cd/var
# Ftp <your-server-ip>
Ftp> bin // transfers files in binary mode
Ftp> get test
Ftp> exit
Then modify the file attributes:
# Chmod + X test
#./Test
Now you can view the results.
2.2 NFS Mode
Mount the shared output directory of the Linux server on the target board and run the program.
# Mkdir/mnt/nfs
# Mount-O nolock-t nfs <your-server-ip>:/home/lqm/mnt/nfs
# Ls/mnt/nfs
The contents of the shared directory of Linux Server are displayed. Then execute:
#./Test
3. Conclusion
These two methods are not very complex in the application time zone, not very large, but when the development program is more complex, the NFS method is obviously much more efficient. After developing the application, you can download it to the Flash file system of the embedded target board after debugging, or compile it directly to the embedded Linux kernel and burn it to flash, and finally become an independent embedded application.
++
Below are some common NFS sharing parameters:
RO: read-only access
RW: read/write access
Sync: Write and share all data upon request
Async: NFS can respond to requests before writing data
Secure: NFS is sent through the secure TCP/IP ports below 1024
Insecure: NFS is sent over port 1024.
Wdelay: if multiple users want to write data to the NFS Directory, group write (default)
No_wdelay: if multiple users want to write data to the NFS Directory, write the data immediately. This setting is not required when async is used.
Hide: do not share its subdirectories in the NFS shared directory.
No_hide: a subdirectory that shares the NFS Directory
Subtree_check: If sub-directories such as/usr/bin are shared, force NFS to check the permissions of the parent directory (default)
No_subtree_check: the parent directory permission is not checked.
All_squash: The UID and gid of the shared file are mapped to the anonymous user anonymous, which is suitable for public directories.
No_all_squash: reserve the UID and gid of the shared file (default)
Root_squash: all requests of the root user are mapped to the same permissions as those of the anonymous user (default)
No_root_squas: the root user has full management access permissions to the root directory.
Anonuid = xxx: Specify the UID of an anonymous user in the NFS server/etc/passwd file
Anongid = xxx: Specify the GID of anonymous users in the NFS server/etc/passwd file
