Issues with NFS Boot on Jetson Xavier using Bridged Interface with DHCP on R32.7.2

[sabrown365]

Hello,

I am currently working on setting up NFS boot on a Jetson Xavier device and have run into some issues I hope to get assistance with. I’m using Jetson Linux R32.7.2 and have been trying to configure the device to boot over NFS using a bridged network interface configured via DHCP and preserve the bridge without severing the nfs connection. NOTE: I’ve been successful with static IP NFS booting, and I’m manually flashing with the script rather than using Jetpack. I’m also using the example rootfs provided by nvidia.

The setup involves bridging the eth0 and eth1 interfaces on the Xavier. I’ve manually modified the init script within the initrd to create the bridge and it appears to set up correctly when I ifconfig in the bootloader. However, I’m unable to acquire an IP address through DHCP for the bridged interface. I have watched the traffic from the DHCP server and the verbose output from the /sbin/dhclient and attempted to correct the errors the /sbin/dhclient spits out.

Here’s a brief overview of the steps I’ve taken so far:

• Modified the l4t_initrd.img init script to set up the bridge on nfs boot. See below for code snippet.
• I’ve tried to fix all errors spit out using /sbin/dhclient by adding arm64 compiled libraries, bin and sbin programs, and missing directories
  – I added brctl
  – I added dhclient-script and all lib.so type deps
  – I added directories that were missing such as /var/lib/dhcp to hold the lease

initrd init script modification in the nfs section:

elif [[ "${rootdev}" == "nfs" ]]; then
        brctl addbr br1
        brctl addif br1 eth1
        brctl addif br1 eth0
        ifconfig eth1 0.0.0.0
        ifconfig eth0 0.0.0.0
        ifconfig br1 up
        timeout 8s /sbin/dhclient br1
        if [ $? -ne 0 ]; then
                echo "ERROR: DHCP Bridge br1 fail..." > /dev/kmsg;
                exec /bin/bash;
        fi;

        nfsroot_path="`cat /proc/cmdline | sed -e 's/.*nfsroot=\([^ ,]*\)[ ,].*/\1 /'`";
        nfsroot_opts="`cat /proc/cmdline | sed -ne 's/.*nfsroot=\([^ ,]*\),\([^ ]*\).*/\2 /p'`";
        if [[ "${nfsroot_opts}" == "" ]]; then
                nfsroot_opts="nolock"
        fi
        mount -t nfs -o ${nfsroot_opts} ${nfsroot_path} /mnt/ &>/dev/kmsg;
        if [ $? -ne 0 ]; then
                echo "ERROR: NFS mount fail..." > /dev/kmsg;
                exec /bin/bash;
        fi;

The bridge itself seems to be getting setup correctly, but dhclient does not seem to be able to assign an IP address to the bridged interface. The init script exits on the nfs mount to bash and I’m able to run ifconfig to see that the br1 interface does not have an ip.

What is odd is I’m able to successfully nfs boot with a single (non-bridged) DHCP interface, a single (non-bridged) static IP, and a bridged static IP. So I know dhcp works and I know the brctl is setting up a static bridge correctly.

I can not modify the interfaces once the OS comes up due to losing the nfs mount.

Could someone provide insight into what might be going wrong or what additional steps I should take to troubleshoot this issue? Any advice on bridging interfaces for NFS boot on the Jetson platform would be greatly appreciated. I can provide more detailed configuration files and script changes if necessary.

Thank you for your time and assistance.

Sean

[linuxdev]

Bridges don’t normally have an address (at least not an IP address) of their own. In the past I’ve used a small Linux PC with three NICs in it, whereby two were a bridge with a lot of filtering protection against attackers (in addition to transparent firewalling it ran snort). The third NIC was entirely private and was the only way to reach the bridge o/s itself, and this is the one with the IP address. The bridge itself was invisible to both my internal computer and to the outside world…as far as they were concerned, this was a piece of copper wire.

This isn’t to say that it is impossible to also assign an address to a bridge, but this is for a multihomed setup and is technically not part of the bridge. I forget all of the changes which have occurred since then, but at some point it became harder to multihome an actual physical NIC…some of the rules changed and I am not up to date on those rules. The setup for dual homing is likely different than you think, and I have to apologize that I don’t know what all of the current rules are. You can see a bridge device though when multiple providers might be used and there is switching between providers. A fully booted Jetson with the virtual USB ethernet for example will have l4tbr0 with an address, but the virtual USB (usb0) will itself not have an address.

Now if there is a third interface, and the bridge acts as a conduit to that interface, then the third interface should have DHCP work as if there is nothing unusual. I wish I was more up to date on bridging, so I can’t help much more, but I will suggest to make sure that a bridge does what you think it does.