Tag Archives: still trying arm

nfs:server 172.168.1.22 not responding,still trying arm Client Configuration

nfs:server 172.168.1.22 Not responding, still trying problem solving platform is realarm 210 platform

nfs:server 172.168.1.22 The platform is realarm 210

The problem here is encountered when using NFS to mount the file system, so here is only the solution to this problem when mounting the file system. Please see the following figure for the situation of problems:

Search on the Internet can find solutions, but they are basically the same, or do not understand, leading to the card I did not solve for a long time. The solutions on the Internet are as follows. Maybe some people’s problems can be solved, but my problems are not

After installing the NFS file system on the host on the mini2440 development board, the following prompt will appear:
NFS: server is not responding, still trying
cause of the problem:
mandag 27 November2006 20:12 skrev Verner kjrsgaard:
> Mandag 27 november 2006 19:33 skrev John P. New:
> > Verner,
> >
> > This is a problem with NFS and 2.6 kernels, fast server NICs and
> > comparatively slower client NICs. This will show up when the server has
> > a 1000Mb card and the client a 100Mb, or when the server has a 100Mb
> > card and the client a 10Mb.
> >
> > Essentially, you have to pass some options to the kernel on terminal
> > boot, and this varies depending on whether you are using etherboot or
> > PXE.
> >
> > See
> > http://wiki.ltsp.org/twiki/bin/view/Ltsp/NFS#NFS_ Server_ not_ responding
> > For a deep explanation of the problem and the cure.

the main idea is that there is a mismatch between the NFS host network card with a higher transfer rate and the target network card with a lower transfer rate. To solve this problem, additional parameters need to be added when mounting the file system<

solution:
1 when the target machine has entered the Linux system after startup, use the following mount command:
mount – t, NFS – O, intr, nolock, rsize = 1024, wsize = 1024 59.70.245.216]/home/Lizhao/rootfs/MNT/NFS
(that is, add the parameter of INR rsize = 1024, wsize = 1024, wsize = 1024 59.70.245.216), When the target machine is in the boot phase and passes command line parameters to the kernel, the following parameters are used:
console = ttysac0 root =/dev/NFS nfsroot = 59.70.245.216]/home/Lizhao/rootfs, flags = intr, rsize = 1024, wsize=1024ip=59.70.245.222:59.70.245.216:59.70.245.216:255.255.255.0: leao:eth0 : off

parameter explanation:
intr — when the server is down or unable to reach, it is allowed to interrupt the NFS request. Nolock — Disable file lock. Rsize = 8192 and wsize = 8192 — increase the speed of NFS reading and writing by setting large simultaneous data block size (bytes). Be careful when changing these values. Some old Linux kernels and network cards don’t work properly in large block sizes

Later, I saw a post saying whether the IP configuration of the system was carried out when loading the file system, which led to such an error (as shown in the figure below). After checking the RCS file, I found that there was a configuration. I’m so excited. Let’s revise it

Since this is shared under Linux (I use Ubuntu version 10.04) system, the modification of files is done directly in Ubuntu. As shown in the figure below:

Look at the diagram circle. Here is a script file loaded. In the same folder as RCS, ifconfig-eth0 is the configuration of IP. OK, let’s take a look at the ifconfig-eth0 script, as shown in the following figure:

There is an if conditional sentence in it. Here, the if conditional sentence is true, and the file is in the/etc directory, as shown in the following figure:

Then the execution here is the source/etc/eth0 setting part in the ifconfig-eth0 script file, which is the box part in the figure below. Without this file, the execution is the else part in the if statement (that is, the ellipse part in the figure below)

It can be seen that the IP configuration file is eth0 setting. Open it and see the following figure:

Because my IP gateway is 172.168.1.1, the IP configuration is not good. In u-boot, the IP gateway is 172.168.1.1, but it is modified to the IP shown in the figure above when mounting the file system. Because of this, the IP is no longer in the same network segment, and the communication fails, so there is no response error. Modify this file as shown in the figure below. Mine is the IP shown in the figure below. Please modify it to your own IP

After modification, save and restart. So it’s completely normal

For other development boards, the RCS script either loads the ifconfig-eth0 script to configure IP or does not have the following sentence:

But there may be the following sentence to configure

Then, modify the IP shown in the figure above

In addition, the environment parameter settings of my u-boot are attached

In the attached settings command:

setenv bootcmd “tftp C0008000 zImage; bootm C0008000 40800000”

setenv bootargs noinitrd root=/dev/nfs console=ttySAC2 init=/linuxrc nfsroot=172.168.1.22:/nfsboot/210system_ new/system ip=172.168.1.21:172.168.1.22:172.168.1.1:255.255.255.0::eth0:on

IP and file system directory can be modified to their own