Hello. Do you have any news about what could be happening?
Hello. Do you have any news about what could be happening? I’ve got one AGX we need stopped,waiting to use at some point to help to debug this. But I need to know this issue is not being ignored, or I will have to keep on using it again at some point.
Is anyone reading this?
Hi masip85,
Do you mean the board can not be detected with JP5.1 but can be detected in JP5.0.2?
If it can not be detected in JP5.1, how did you flash it back to JP5.0.2?
Could you help to state the exactly problem you met?
and I’ve explained that docker would be unstable for the connection between the host PC and the board.
-
Yes. One versions detects the jetsons in selection panel, the other one doesn’t.
-
But the best of both, ends with
│info: Waiting for target to boot-up..
(only when using internal nvme), emmc installation works fine
3- Unstable means I cannot use it? I watch lsusb and remains connected. And why in that case emmc installation works just fine?
There’s no internal NVMe, just eMMC…
You may use that. For our experience, we would just suggest to use standalone Ubuntu as your host PC to develop the Jetson.
I’ve installed an nvme inside the xavier! I know is not included XD . And I can install the jetpack on it perfectly. Normally I use the jetsonhacks github code (bootFromExternalStorage) or I do it manually myself.
So what the problem with it? Why I can install perfectly on emmc but I cannot install on nvme?
If you wonder about my personal machine linux version, this is it:
Regards
I would not know the exactly cause of this problem
For using NVMe as rootfs, you could refer to the following steps to flash into NVMe drive.
Flashing Support — Flashing to an NVMe Drive
Yes, with commands I can do it successfully. Manually, I can do it, but as always, I need to have different ubuntu versions for different jetpacks.
And yes , I can do it with sdkmanager with no problem. but I need also different Ubuntu versions.
That’s the reason I want to move from manually to docker sdk manager. I guess that is the foundation of docker sdk manager, the ability of doing it without being worried of Ubuntu Os versions.
We’d like to move forward and being able of doing this with docker. Can you reproduce the issue? Or it’s only me?
That’s not exactly.
For JP4, Ubuntu 16.04/18.04 are both supported.
For JP5, Ubuntu 18.04/20.04 are both supported.
There’re also many minor versions in bothe JP4/JP5.
We would not suggest using docker/VM/WSL2 to develop Jetson. If you really wants to use docker, please help to provide the detail reproduce steps and related flash/serial log. I would help to verify from my side.
I provided log right here:
Our equipment systems are updated to 22.04. So I need partitions for 18.04, and 20.04. 3 different ubuntu systems. I thought I could claim back all that disk space if I flash with docker.
So docker came to rescue for me. You don’t suggest to use it? why?
Regards
Ubuntu18.04 would be the suggested version in use due to supporting both JP4/JP5 for your AGX Xavier.
I’ve explained above (unstable connection to host PC, unexpected errors of filesystems and system packages). We work on the standalone Ubuntu PC and are familiar with the issues on it.
error: exportfs: /home/nvidia/nvidia/nvidia_sdk/JetPack_5.0.2_Linux_JETSON_AGX_XAVIER_TARGETS/Linux_for_Tegra/rootfs does not │
│support NFS export
From your error flash logs, it seems causing from wrong type of filesystem to me.
Because other software minimum requirements, we cannot use Ubuntu 18. It is an OS 5 years old, with much more issues than 20 or 22 for daily basis using.
I’ve never had format nvme necessity previously. flash command doesn’t do it? How should I format it?
Please notice Ubuntu20 and 22 not work with JP4.x (R32.X).
You should format the NVMe SSD as ext4 before use. You might need using fdisk
command.
Why I can install perfectly on emmc but I cannot install on nvme?
This involves the mechanism of the flash script.
Flashing to emmc and nvme are totally different flow from the beginning… If you want to know the detail, then I can explain to you. But I don’t guarantee you would understand it because this requires some knowledge about the boot flow…
Yes, what I meant, if this could be a (re)connection issue, my thinking was the problem would be for flashing emmc and nvme because host pc can’t connect to all xavier. But yes,I am completely noob in these boot flow issues, and my thinking could be completely wrong.
Few days ago I posted here this was solved. It is not, this was a message for another post…
So, with an ext4 formatted disk I’ve obtained:
│info: [OEMPreconfig] SDKM_INSTALL_ERROR Password for L4T new user nvidiatemp: │
│info: │
│info: External storage specified nvme0n1p1 │
│info: Flashing Jetson Xavier │
│info: /home/nvidia/nvidia/nvidia_sdk/JetPack_5.1.1_Linux_JETSON_AGX_XAVIER_TARGETS/Linux_for_Tegra/tools/kernel_flash/l4t_initrd_flash_internal.sh --no-flash --external-device nvme0n1p1 │
│-c tools/kernel_flash/flash_l4t_external.xml --showlogs --network usb0 -p -C nv-auto-config jetson-agx-xavier-devkit nvme0n1p1 │
│info: * Stopping NFS kernel daemon │
│info: ...done. │
│info: * Unexporting directories for NFS kernel daemon... │
│info: ...done. │
│info: * Not starting NFS kernel daemon: no exports. │
│error: exportfs: /home/nvidia/nvidia/nvidia_sdk/JetPack_5.1.1_Linux_JETSON_AGX_XAVIER_TARGETS/Linux_for_Tegra/rootfs does not support NFS export │
│info: Cleaning up...
Cannot you reproduce the issue?
Regards
We usually develop Jetson on standalone Ubuntu PC, and we don’t suggest to use docker for SDKM. If you really have to develop on it, please help to provide the detailed reproduce step about how you setup the docker and any command you use and the related flash log from host and the serial console log from the board.
Right now I don’t have available xaviers to keep on debugging this.
Do you mean that Ubuntu Host really works for every container SDKM? Anyway, if I need an specific standalone Ubuntu PC, I don’t get the purpose of creating docker images with SDKM.
This topic was automatically closed 14 days after the last reply. New replies are no longer allowed.