NFS -: server not responding, still trying -upstream-Tezi_7.x - iMx6

Technical Support
, , , , ,
1

Dear Community,

I’m facing an issue with NFS. I’ve followed the steps described in “Developper section” to install and configure tftp-hpa and nfs-kernel-server on my host machine. I take image from Download Links | Toradex Developer Center

I try on three different OS Ubuntu 16, 22 and 24. On Ubuntu 16 I have working nfs for image 2.8.

Bootlog ends here:
[ OK ] Started User Login Management.
[ OK ] Started Connection service.
Starting Avahi mDNS/DNS-SD Stack…
[* ] (1 of 2) A start job is running for…ork Configuration (51s / 1min 50s)
[ 209.125244] nfs: server 192.168.10.1 not responding, still trying
[ 209.134592] nfs: server 192.168.10.1 not responding, still trying

I try also on two different boards (one custom and Iris).

From wire shark and chat GPT I get:
No. Time Source Destination Protocol Length Info
81902 36.088070849 192.168.10.2 192.168.10.1 NFS 178 V3 GETATTR Call (Reply In 81903), FH: 0xd8f1ffc1
81903 36.088168720 192.168.10.1 192.168.10.2 NFS 182 V3 GETATTR Reply (Call In 81902) Regular File mode: 0755 uid: 0 gid: 0
81904 36.088201576 192.168.10.2 192.168.10.1 NFS 178 V3 GETATTR Call (Reply In 81905), FH: 0xd3b84cdb
81905 36.088297170 192.168.10.1 192.168.10.2 NFS 182 V3 GETATTR Reply (Call In 81904) Regular File mode: 0755 uid: 0 gid: 0
81906 36.088854106 192.168.10.2 192.168.10.1 NFS 178 V3 GETATTR Call (Reply In 81907), FH: 0x58fc9d29
81907 36.088935273 192.168.10.1 192.168.10.2 NFS 182 V3 GETATTR Reply (Call In 81906) Regular File mode: 0755 uid: 0 gid: 0
81908 36.295980078 192.168.10.1 192.168.10.2 TCP 182 [TCP Retransmission] 2049 → 973 [PSH, ACK] Seq=36743621 Ack=4632701 Win=706304 Len=116 TSval=1165810797 TSecr=1765619725
81909 36.503982270 192.168.10.1 192.168.10.2 TCP 182 [TCP Retransmission] 2049 → 973 [PSH, ACK] Seq=36743621 Ack=4632701 Win=706304 Len=116 TSval=1165811005 TSecr=1765619725
81910 36.919814980 192.168.10.1 192.168.10.2 TCP 182 [TCP Retransmission] 2049 → 973 [PSH, ACK] Seq=36743621 Ack=4632701 Win=706304 Len=116 TSval=1165811421 TSecr=1765619725
81911 37.759751515 192.168.10.1 192.168.10.2 TCP 182 [TCP Retransmission] 2049 → 973 [PSH, ACK] Seq=36743621 Ack=4632701 Win=706304 Len=116 TSval=1165812261 TSecr=1765619725
81912 39.423971584 192.168.10.1 192.168.10.2 TCP 182 [TCP Retransmission] 2049 → 973 [PSH, ACK] Seq=36743621 Ack=4632701 Win=706304 Len=116 TSval=1165813925 TSecr=1765619725
81913 42.751979674 192.168.10.1 192.168.10.2 TCP 182 [TCP Retransmission] 2049 → 973 [PSH, ACK] Seq=36743621 Ack=4632701 Win=706304 Len=116 TSval=1165817253 TSecr=1765619725
81914 49.663790830 192.168.10.1 192.168.10.2 TCP 182 [TCP Retransmission] 2049 → 973 [PSH, ACK] Seq=36743621 Ack=4632701 Win=706304 Len=116 TSval=1165824165 TSecr=1765619725
81915 62.975808247 192.168.10.1 192.168.10.2 TCP 182 [TCP Retransmission] 2049 → 973 [PSH, ACK] Seq=36743621 Ack=4632701 Win=706304 Len=116 TSval=1165837477 TSecr=1765619725
81916 89.599812698 192.168.10.1 192.168.10.2 TCP 182 [TCP Retransmission] 2049 → 973 [PSH, ACK] Seq=36743621 Ack=4632701 Win=706304 Len=116 TSval=1165864101 TSecr=1765619725
81917 94.719748116 TpLinkTechno_a6:f6:b1 Toradex_4f:f8:aa ARP 42 Who has 192.168.10.2? Tell 192.168.10.1
81918 95.743851595 TpLinkTechno_a6:f6:b1 Toradex_4f:f8:aa ARP 42 Who has 192.168.10.2? Tell 192.168.10.1
81919 96.767735769 TpLinkTechno_a6:f6:b1 Toradex_4f:f8:aa ARP 42 Who has 192.168.10.2? Tell 192.168.10.1
81920 144.383994437 TpLinkTechno_a6:f6:b1 Broadcast ARP 42 Who has 192.168.10.2? Tell 192.168.10.1
81921 145.407737102 TpLinkTechno_a6:f6:b1 Broadcast ARP 42 Who has 192.168.10.2? Tell 192.168.10.1
81922 146.431968294 TpLinkTechno_a6:f6:b1 Broadcast ARP 42 Who has 192.168.10.2? Tell 192.168.10.1
81923 197.631939214 TpLinkTechno_a6:f6:b1 Broadcast ARP 42 Who has 192.168.10.2? Tell 192.168.10.1
ChatGPT said:

This network capture indicates a communication issue between two hosts using NFS (Network File System) over TCP, particularly between:

192.168.10.1 (likely the NFS server or gateway)

192.168.10.2 (likely the NFS client)

Summary of Key Events

Initial NFS GETATTR Calls (Normal Communication):

    Packets 81902–81907 show normal NFS traffic (GETATTR calls and replies), confirming that the connection was initially healthy.

Retransmissions Begin:

    Starting at packet 81908, 192.168.10.1 begins retransmitting a TCP segment to 192.168.10.2 (port 973) repeatedly. This retransmission continues across multiple time intervals, up to packet 81916 (at ~89 seconds), suggesting 192.168.10.2 is no longer responding.

ARP Requests:

    From packet 81917 onward, the device with MAC address TpLinkTechno_a6:f6:b1 (associated with IP 192.168.10.1) starts issuing ARP requests asking “Who has 192.168.10.2?” This is a clear sign that it no longer knows how to reach 192.168.10.2 — possibly because:

        192.168.10.2 went offline

        There's a network issue

        192.168.10.2 changed IP/MAC unexpectedly

Interpretation

This log strongly suggests that:

The device at 192.168.10.2 became unreachable (possibly powered off, crashed, or disconnected from the network).

The NFS server continued trying to send data, failing repeatedly, then fell back to ARP to try to rediscover the client's MAC address, but got no response.

The lack of replies to ARP and TCP retransmissions confirms the loss of network connectivity to 192.168.10.2.

Has anyone had similar problems and any ideas what I can do?

2

Hi, I’m the Toradex AI Assistant.

I might make mistakes. Our support team will step in if needed. If I answered your question, please tick the “Solution” checkbox. For follow-up questions to me, please use @ToradexAI in your post.

Did you like my answer? :+1: :-1:

Hello! Thanks for sharing such a detailed description and network trace.

Based on your boot log, network capture, and testing across different Ubuntu hosts and Toradex carrier boards, here are some troubleshooting steps tailored for Toradex embedded Linux with NFS boot:

Key Points from Your Description

  • Initial NFS traffic is successful (GETATTR calls and replies).
  • Then the client (the Toradex device) becomes unreachable—network communication stops, and ARP requests from the server go unanswered.
  • You are stuck during early userspace/network initialization (Avahi, ConnMan, etc.).

Common Causes and Solutions

1. DHCP and NFS Configuration

  • Check that your DHCP server provides the correct root-path option and the client receives it:

    option root-path "192.168.10.1:/srv/nfs/rootfs,wsize=1024,rsize=1024,v3";

    (Reference)

  • Your /etc/exports should look like:

    /srv/nfs/rootfs 192.168.10.2(no_root_squash,no_subtree_check,rw)

    Remember to run:

    sudo service nfs-kernel-server restart

    after any change.
    (Reference)

2. NFS Version Compatibility

  • If you are using NFSv3 (which is standard for kernel boots), make sure your server is exporting as v3 and not v4. For v4, the configuration is slightly different:
    /srv/nfs 192.168.10.1/24(no_root_squash,no_subtree_check,rw,fsid=root)
    (Reference)

3. ConnMan Interference

  • The connman service on recent Toradex images can take down and reconfigure the network interface after boot, causing loss of connectivity—including to the NFS server.

  • If the boot halts after “Started Connection service,” it’s likely connman is reconfiguring the interface, breaking your NFS root.

  • Solution: Try disabling connman on your image for network boot scenarios.

    systemctl disable connman

    or pass connman.disable on the kernel command line as appropriate.

    (Reference)

4. General Network Troubles

  • Check for duplicate IPs or DHCP assignment conflicts in your network setup.
  • Verify cabling and switch stability.
  • If you are using a USB Ethernet adapter on the Toradex board, ensure it is reliable and fully supported.

5. File System Permissions

  • Ensure the NFS export’s root directory has correct ownership and permissions (typically root:root and at least 755).

Next Steps

  1. Double-check your root-path and /etc/exports settings on the server.
  2. Ensure the correct NFS version is set.
  3. Try disabling connman or adjusting its settings as it is known to interfere with static/manual/early network setups.
  4. If you update the configuration, always restart the relevant services and/or reboot.
  5. Use the serial debug console to watch for kernel/networking errors during boot.

For further details, refer to:

If you try these steps and still encounter the issue, please share your /etc/exports, DHCP config, and image version info. This will help narrow down the problem.

Best regards,
Toradex AI Assistant.

3

I add to tdx-reference-minimal-image.bb:
KERNEL_EXTRA_ARGS += “connman.disable”

and into local.conf:
IMAGE_INSTALL:remove = “connman”
DISTRO_FEATURES:remove = “avahi”
IMAGE_INSTALL:remove = “avahi-daemon”

still the same error.

4

Hi @medicalSpark !

I will try to reproduce it on my side and get back to you on this.

Best regards,

5

It’s look very similar to this post Boot from a TFTP/NFS Server - #6 by vishvas But I don’t see the solution.

6

Hi @medicalSpark !

I invested some time on it and managed to get it working on my side.

Configuration on TFTP/NFS/DHCP is needed, which is a bit long to write everything down here.

I created an internal documentation and exported it to PDF (attached below). Could you please try to follow it and let me know if it works for you?

Please note that I did it for Aquila AM69 at first. Then I added to the end my configuration for Colibri iMX6DL. I hope it is not confusing.

Please also note that this is just a simple write-up I did to try to help, and this is not official documentation.

Booting from TFTP-DHCP-NFS on Reference Image from BSP 7.2.0.pdf (1.9 MB)

Let us know how it goes.

Best regards,