Jetson Orin Nano Headless setup ready to SSH


I’m using Jetson Orin Nano 8 GB Developer kit and 35.3.1 Jetson version.

I used the sample fs and 35.3.1 package to setup without gui followed the instructions flashing is done without any problem but my problem is I couldn’t make it ready to ssh. When I off the recovery mode and restart in the GUI also still asks add a new user and first configuration settings but script says the user is already added.

I use default user script to add a user but I have two problem.

First, Even though it says the user is created I cannot ssh to it with LAN IP and username
Second, How can I set wireless connection?

Thanks and have a great day.

I have no idea what you are talking about.
What is LAN IP here?
How would you know the IP without accessing the device in some other ways like GUI or serial console?
Or you mean with the USB-C cable?
What is wireless connection here?

I’m using nmap before and after connection when the device connected via ethernet cable connection to internet.

I meant wifi connection configuration.

Can you please elaborate it more?
I still don’t know what you are trying to do.

After flashing the Orin Nano, I connect the device with an Ethernet cable and then I plan to connect to it via SSH. I scan for IP addresses with nmap while the device is both off and on. I can tell which IP belongs to the device if it appears when scanning with nmap. I want to connect to it using SSH.

The other thing I want to do is connect the device to a Wi-Fi network after flashing it, using the network name and password without GUI.

Then are you able to login to the device with serial console or with the flashing cable?
For Wi-Fi connections, there is a whole bunch of documents online:

How can we set up the Wi-Fi configuration on the Orin Nano while it’s in recovery mode, through the host machine?

I cannot connect via SSH with the username and password I created when the device’s IP is

YES or NO?
Why is it in recovery mode?

Can you record a video of what have you done so far?
Our conversation has been very ineffective.

I put the device into recovery mode using the host machine to flash it. Then, while it’s still in recovery mode, I create a user from the host machine. During this process, without turning on the device, I want to set up the Wi-Fi configuration and get it ready for SSH connection. I don’t understand what you mean in the sentence you quoted

How are you able to do this? It should be done before flashing.

I did this after the flash. It won’t show any error.

Yeah, it won’t show any error, but it also will not take effect.
Please do it before flash.

OK, so it will be ready to SSH after I’ve done the steps in correct order. I see oem config for wifi configuration too.

Also, I don’t think this is possible.
Use GUI or wired connection when you log in to the device for the first time.

1 Like

I don’t know all of what you are doing, and I don’t consider this an answer, but it will probably help you in future questions…

During flash the Jetson is a custom USB device. The rootfs partition (“/”) comes mostly from the host PC’s “Linux_for_Tegra/rootfs/”. Some of the /boot content, including kernel and extlinux.conf and device tree, gets edited depending on what the flash target is (the content changes with model of Jetson and model of carrier board, plus perhaps some customizations such as alternate boot media…it is very important to know if you are using alternate boot media).

That content normally does not contain an admin user due to California law regarding default name/password being discouraged. That content also does not contain much of the optional content, e.g., it won’t include CUDA.

Once flash is complete the Jetson will automatically reboot. This is when it wants first login account setup. Although you did not power cycle the Jetson it has done so automatically and is no longer in recovery mode. This means the Jetson is no longer a custom USB device. The part of flash which actually flashes is known as the “driver package” because it understands this custom USB device, but that software no longer has any participation in steps that follow.

The fully booted Jetson, once it has first boot account setup complete, will have optional software installed by JetPack (such as CUDA). That software is installed via ssh. You could name a custom IP address over the wired ethernet, but the Jetson has a trick up its sleeve with its USB which had previously been used as a custom device: During fully booted operation, that USB pretends it is a router device. The host PC sees that USB device, and unless security blocks it, the host will configure this router for use and send out a DHCP request. The Jetson assigns address to the host PC, and also assigns as the address to itself. The host PC can use ssh to the login account at address while fully booted (but not while truly in recovery mode). Or you can also use a custom IP address if the wired ethernet is assigned an address. Wi-Fi is problematic for reasons mentioned below.

At this point the important notes are:

  • The Jetson self-reboots after flash. It isn’t obvious.
  • Optional content is via JetPack over ssh, while base content is via “Linux_for_Tegra/rootfs/”.
  • ssh can use address if and only if the rebooted Jetson’s virtual network router is accepted by the host PC. From the host PC you would be able to see this with ifconfig (or ip -s addr). Or you could “ping”. ping is a good test because not only does it look for the address, it checks if there is a response. If there is no response, then probably the host PC refused the network device due to security settings.

Wi-Fi setup is not something NVIDIA has anything to do with. This is an “Ubuntu thing”. Many other Linux distributions do exactly the same thing. Wi-Fi is a “managed” network device, meaning it has code actively doing different things with it depending on circumstances. Wi-Fi tries to be a sort of mobile and flexible service, and is usually tied to individual users due to passwords. The default is that Wi-Fi only starts when the user logs in to the GUI itself. This also typically disables the wired, or else uses the metric to switch to Wi-Fi.

You could research this, and set it up so that Wi-Fi is connected even if no user is logged in. If both Wi-Fi and wired ethernet run, then the routing tables start to matter. The device with the lowest metric (least cost) will be used. This can be fixed, or it can vary by subnet. The correct way to deal with this depends on your specific circumstances, and so it is hard to answer how this would be set up if you set Wi-Fi to be always on.

Going back to previous paragraphs, remember how I said that other than what is basically the kernel and boot setup, that the rest of “Linux_for_Tegra/rootfs/” becomes an exact copy of what the root filesystem is? As long as you don’t touch those few items (e.g., kernel or device tree or extlinux.conf) you can edit this to your own custom desire and that edit will appear after every flash.

One such utility which exists with the flash software is “Linux_for_Tegra/tools/”. You mentioned something in your first post that makes me think maybe you used this, but I will restate that this modifies rootfs/ with a default user (and you only do this once from Linux_for_Tegra/):
sudo ./tools/

Now I am going to switch gears (I’m not really changing the topic, this is related to and regress to some of the flash options. I mentioned that external media or some other flash options can change what happens during a flash. Alternate media often implies that part of one memory device (such as eMMC or SD card) is used early on in boot, but another device is used for the rest of boot. It also means use of an initial ramdisk (initrd) as a kind of adapter between filesystems, whereby there is a chain of devices during boot. If some options exist related to alternate media, then it is possible that even with that the changes will be going to one device, but not to another; during a chain load of devices it might be required that you create those same edits that created, but on the other media.

An interesting concept is also that one can clone a rootfs, and use that for flashing. As an example, you could completely update after a flash, set up networking (including Wi-Fi) the way you wish, and clone this, then flash using the clone. Everything will be exactly as you cloned. Almost the same, you could use your clone to replace “Linux_for_Tegra/rootfs/” (the kernel, device tree, and extlinux.conf would still be updated). Or you could use rsync to update rootfs/ over the network from Jetson to host PC. The lesson is that if you have your Jetson set up the way you want it, then you can save your work to the host PC and have that content available every time you reflash. There are just so many ways to do that it is hard to list them all.

rsync is your friend. Cloning is your friend.

I was asking how I can perform configuration processes, create a user, selecting language, keyboard, timezone and connect to a Wi-Fi internet network through the host device without a GUI, just after flashing the device.

At this link It mentions oem-config here and states that we can establish the configuration included wifi. Could not I use this?

When we connect the Orin Nano to recovery mode with the help of a jumper, it cannot exit the recovery mode once it restarts itself as far as I know.

You should do this with the help of serial console:

Configuring Wi-Fi from host setup is quite problematic. The reason I mentioned how the rootfs/ is used is that you can set it up once on a running Jetson, and then copy that into the host PC for future flashes. Wi-Fi setup is not simple, but wired ethernet uses a simple DHCP so wired automatically works without effort.

This topic was automatically closed 14 days after the last reply. New replies are no longer allowed.