I’m trying to flash a Jetson Orin NX on a custom carrier board with our own BSP.
Because the full JetPack SDK sits on a remote server, I mount its installation directory on my local host over NFS and then run l4t_initrd_flash.sh.
Everything goes smoothly until the actual flash step, where the script stops with: requires fsid= for NFS export
Has anyone dealt with this fsid= requirement when flashing from an NFS-mounted JetPack install? What’s the best fix—adding an explicit fsid, using a bind-mount, or something else entirely?
Any pointers would be greatly appreciated. Thanks in advance!
Is the entire “Linux_for_Tegra/” location NFS? Or is it just the “rootfs/” which is NFS? Also, are you using NFSv3 or NFSv4? Does the content inside of “rootfs/” show full Linux style permissions? I ask this latter because there are a number of underlying filesystems which NFS can export, and more importantly, there are options on what the mount point will do regarding root user access and changes (often there are restrictions or numeric account ID translations).
I am using NFSv3 to mount the whole “Linux_for_Tegra/ ” folder from a remote server connected to our system, and yes, the content inside “rootfs/ ” shows the usual Linux style permissions, but somehow during the flashing I get this error.
I am using sudo mount -t nfs ........ top mount the “Linux_for_Tegra/ ” Folder
I am only guessing, but flash is normally from an ext4 filesystem. If someone were to use the wrong filesystem type, e.g., NTFS, then flash would appear to succeed, but the flashed software would fail. Is the software being flashed from L4T R36.x or R35.x (see “head -n 1 nv_tegra_release” on the host PC after you cd to “Linux_for_Tegra/rootfs/etc/”)? I’m thinking that if R36.x, then this is a check of filesystem type which did not exist in earlier releases. R36.x is when there was a switch to mainline kernel, and perhaps there are other changes which came with it. Overall though, any Linux filesystem type which is capable of preserving Linux filesystem permissions (including sticky bits and suid/sgid) should work, and this might be overlooking NFS. One would need to mount the NFS with no root squash, and other options such that numeric IDs are preserved and one can execute content as root, so on. I have not used NFS for flash, but do use it regularly (NFSv4) for other purposes. If your NFS truly preserves numeric IDs and allows root execution, so on, then it seems possible it should work.
Maybe @KevinFFF or @DavidDDD or @WayneWWW could look up if there is now a filesystem type check for “rootfs/” or “Linux_for_Tegra/”, but you’ll need to mention which JetPack or L4T release you are using since this might be new for L4T R36.x/JetPack 6.x.
Hi again,
Sorry for the late reply, I was sick last week. @linuxdev : regarding your questions:
The software is flashed from # R36 (release), REVISION: 4.3, GCID: 38968081, BOARD: generic, EABI: aarch64, DATE: Wed Jan 8 01:49:37 UTC 2025
I am mounting also the Linux_for_Tegra folder with no_root_squash
@KevinFFF
I am mounting the Linux_for_Tegra folder to my system at /home/nasif/mnt/
the etc/exports has this inside /home/nasif/mnt *(rw,fsid=1,sync,no_root_squash,no_all_squash,no_subtree_check) #/home/nasif/mnt/nvidia_sdk/JetPack_6.2_Linux_JETSON_ORIN_NX_TARGETS/Linux_for_Tegra/rootfs *(rw,fsid=123,sync,no_root_squash,no_all_squash,no_subtree_check) /home/nasif/mnt/nvidia_sdk/JetPack_6.2_Linux_JETSON_ORIN_NX_TARGETS/Linux_for_Tegra/rootfs *(rw,sync,no_subtree_check,fsid=65656565)
Somehow, the logs aren’t saved due to an incomplete flash which is weird, but as I said, everything is working fine with no suspicious logs until it reaches the step of starting the flash, it shows those lines,
sudo ./tools/kernel_flash/l4t_initrd_flash.sh --showlogs --network usb0 --flash-only rpcbind: another rpcbind is already running. Aborting Export list for localhost: /home/nasif/mnt/nvidia_sdk/JetPack_6.2_Linux_JETSON_ORIN_NX_TARGETS/Linux_for_Tegra/rootfs * /home/nasif/mnt * rpcbind: another rpcbind is already running. Aborting Export list for localhost: /home/nasif/mnt/nvidia_sdk/JetPack_6.2_Linux_JETSON_ORIN_NX_TARGETS/Linux_for_Tegra/rootfs * /home/nasif/mnt * exportfs: /home/nasif/mnt/nvidia_sdk/JetPack_6.2_Linux_JETSON_ORIN_NX_TARGETS/Linux_for_Tegra/rootfs requires fsid= for NFS export
I hope this helps and thanks for the support
I am a bit confused now but let’s start from the beginning. The Qnap server which I am using exports its files so I can mount them into my system. Then this is the exports file of the server: exports (server).txt (338 Bytes)
After mounting the Linux_for_Tegra folder, I have the same Folder at my system and When I try to flash it gives me this error: exportfs: /home/nasif/mnt/nvidia_sdk/JetPack_6.2_Linux_JETSON_ORIN_NX_TARGETS/Linux_for_Tegra/rootfs requires fsid= for NFS export, Then the problem is with my host exports which is now: exports (Host-Client).txt (158 Bytes)
Which one I should change and exactly should I write inside?
I don’t know why but I was thinking this was NFSv3, but I think the above is still true. One thing about the first exports file of the Qnap server I’m hoping to clarify though is which export line is for mount of the “rootfs/” on the host PC? Despite naming conventions I don’t want to guess. If I were to guess though, is the exports line for the rootfs/ this one? "/share/NFSv=4" *(no_subtree_check,no_root_squash,insecure,fsid=0)
If it is, then it might be a case of editing the “fsid=0” and changing it to “fsid=1” on the Qnap server.
You originally had “fsid=0” for “/share/NFSv=4”. Maybe that isn’t even the export you are using for that part, but if it is, then that is likely the problem. What do you see for this from Linux side which imports? egrep -i nfs /etc/mtab
I’d just like to establish the actual NFS import and export options (import might change something; export from the server, import from the mount side).
Does that have fsid=1 in the exports file? The import side won’t know specifically about that (which is what the mtab is…the mount/import side).
I’m not sure where to go from there. One would have to know the exact command within the initrd flash script where this happens, and be able to trace exactly what is going on. I cannot personally recreate this, I do not have the setup for it. Perhaps @KevinFFF might be able to see the exact script line which produces that specific mount event. I’m not surprised that NFS mounts for that are an issue since there is code being executed there (in part at times by QEMU in arm64 mode). The export side though, if it has the fsid=1, should allow root to execute and otherwise deal with root content.
On your QNAP server, please put JetsonHub under /share/NFSv=4/, the full path should be /share/NFSv=4/JetsonHub
After you’ve finish above modification, please run the following command to mount.
It isn’t about mounting the Linux_for_Tegra Folder over NFS from the QNAP server; this works and is verified.
However, this issue has been occurring since the L4t_intrid_flash.sh script re-exports the rootfs and kernel image folders again, making them visible to the Jetson, which causes the conflict.
When I am commenting out the NFS sharing part from the scripts, the flashing is starting fine and sending blob to the Jetson and crashing again since the Folders are still not shared properly.
I’ve done some research on how to re-export NFS, which seems not to be possible or considered as a bad practice. My current solution that I will take a copy from the Server and run it locally, which isn’t the best case for us. If you have any clue how to overcome this, it would be perfect.
