Cannot connect via ssh on initial setup sdkmanager

Hi, I’m new to this and am currently setting up my Jetson Orin Nano on a host computer with Ubuntu 20.04 (JetPack 5.1.4). I’m stuck in the “SDK Manager is about to install SDK components on your Jetson Orin Nano module” screen. It is requesting for an IP address.

It tells me that it “Cannot connect to the device via SSH. Check the IP address, and make sure that SSH service is running on the device.”

I can ping the device at 192.168.55.1 (both usb and Ethernet connected, but Ethernet has the 192.168.55.100 address). Attempting to ssh gives: ssh: connect to host 192.168.55.1 port 22: Connection refused

I try to access the serial console in hopes of somehow enabling it with screen /dev/ttyACM0 115200 but I only get a black screen. I tried waiting for a while and still nothing. I do not have a monitor on hand right now and would like to set up the Orin Nano without a monitor if that’s possible.

This will probably not solve the issue, but it is some background you will want to have. Perhaps flash did not work.

Do note that there are dev kit Orin Nanos, and they do not have eMMC; the SD card connector is on the module itself. There are also commercial Orin Nano modules which have eMMC, and there is no SD card connector on the module; any SD card for the eMMC model would be on the carrier board. The flash software and requirements are vastly different between those two models. You should state exactly which model you have; if flashing for the wrong model, then a simple change in flash software would solve the problem. I am assuming this is the SD card “dev kit” model without eMMC.

Serial console itself should work even under very bad conditions. If you monitor serial console after rebooting (use the power cycle if you have to, although normally I would not recommend that) and watch for output. Also, you might describe which wire/cable/connector you used with serial console (there is more than one serial port).

During flash the Jetson is in recovery mode. Recovery mode, in and of itself, does not change anything, and the flash software is required to actually make changes. Once the flash is complete, the Jetson automatically reboots. It is this fully rebooted Jetson that has a running operating system. But, an SD card dev kit model isn’t quite the same as the eMMC model.

When you flash a dev kit Nano (original on up to the current Orin Nano) you are flashing QSPI memory. This is what contains the equivalent of a BIOS and boot chain software (on an eMMC model this goes into binary partitions of eMMC). The SD card contains only the operating system. A major release of L4T (L4T is what actually gets flashed, and is just Ubuntu with NVIDIA drivers) on QSPI can only work with an SD card that uses the same major release. So if you flashed R35.x into the module’s QSPI, then the SD card must contain an R35.x release. Similar for R36.x. Mixing an R36.x with R35.x will fail.

Most people end up using a pre-built SD card image and not creating their own, although JetPack/SDK Manager (which is the installer software) can also create an SD card image. Assuming this is a dev kit, are the SD card image and the flashed module using the same major release? It is common to flash the module once, and from then on you can use any SD card of that release (one does not need to flash the QSPI for each release if you stay in that release).

It is also possible something else went wrong. I say this because serial console usually gives some sort of output or sign of life when booting.

After much frustration I did simply press skip, and NVidia SDK manager says that flash was successful (with installation skipped). Also, sorry I didn’t mention, this is the original Jetson Orin Nano 8GB Developer Kit (I didn’t buy a custom one like from Yahboom, etc.)

I’ve read a forum post somewhere that someone resolved this by connecting a DP monitor first which somehow resolved the issue. Unfortunately, I cannot test this since again I don’t have a monitor yet.

I’ve also read somewhere that SSH only works after initial set-up on the Orin Nano is completed, which apparently can be done headless by accessing serial console via the “screen” command. Again, running screen command shows nothing even after waiting. I could be misinterpreting something, however. Is it correct that the serial console is accessible simply via the USB-C connection/Ethernet or do I still have to do something else to access the serial console?

Also:

How do I check for this?

By the way, thanks for the response on my post, it is much appreciated.

Hello, a small update on my side and what I’ve done so far.

Before coming to the forums I had tried flashing JP 6 on the board but it always got stuck at flashing 99% where it would stay indefinitely (tried waiting for hours but no progress so I dropped it). I had also tried downloading the SD card image then using Balena etcher to flash it to my SD Card (JP 5.1.2 and 6) and tried booting it on a DP monitor that I had borrowed and it would shut down immediately after passing the initial loading screen. I no longer have that DP monitor.

Now, earlier today I attempted to install SDK Components by connecting the Jetson Orin Nano to my laptop. First I tried not putting it in recovery mode then plugging in both Ethernet and USB cable to my laptop. Nothing happened, except for the Orin Nano turning on the fan for a brief moment before the fan turned off. Then, I turned the Orin Nano off, placed it in recovery mode, turned it back on, then connected it again to my laptop. SDK Manager is now able to detect the device but still cannot install components, telling me the same error.

The strange thing I observed is when I checked for ttyACM0 for another attempt to access the serial console, I cannot see it anymore.

I proceeded to reflash via SDK Manager. First trying JP 5.1.2. but it would instantly fail for some reason. Then, I tried JP 5.1.4. and it goes fine, until I’m back at the very same spot I was stuck before.

I’ll try to be as detailed as possible with everything I have tried and tested so far.

Checking ifconfig, these were the default values of each interface:


jmescarro@jmescarro-System-Product-Name:~$ ifconfig 
docker0: flags=4099<UP,BROADCAST,MULTICAST>  mtu 1500
        inet 172.17.0.1  netmask 255.255.0.0  broadcast 172.17.255.255
        ether 02:42:96:bf:5a:4c  txqueuelen 0  (Ethernet)
        RX packets 0  bytes 0 (0.0 B)
        RX errors 0  dropped 0  overruns 0  frame 0
        TX packets 0  bytes 0 (0.0 B)
        TX errors 0  dropped 0 overruns 0  carrier 0  collisions 0

enxee586d880382: flags=4163<UP,BROADCAST,RUNNING,MULTICAST>  mtu 1500
        inet 10.42.1.1  netmask 255.255.255.0  broadcast 10.42.1.255
        inet6 fe80::550:1a43:93a8:5d3a  prefixlen 64  scopeid 0x20<link>
        ether ee:58:6d:88:03:82  txqueuelen 1000  (Ethernet)
        RX packets 73  bytes 9771 (9.7 KB)
        RX errors 0  dropped 0  overruns 0  frame 0
        TX packets 28  bytes 4550 (4.5 KB)
        TX errors 0  dropped 0 overruns 0  carrier 0  collisions 0

lo: flags=73<UP,LOOPBACK,RUNNING>  mtu 65536
        inet 127.0.0.1  netmask 255.0.0.0
        inet6 ::1  prefixlen 128  scopeid 0x10<host>
        loop  txqueuelen 1000  (Local Loopback)
        RX packets 5953  bytes 1069382 (1.0 MB)
        RX errors 0  dropped 0  overruns 0  frame 0
        TX packets 5953  bytes 1069382 (1.0 MB)
        TX errors 0  dropped 0 overruns 0  carrier 0  collisions 0

usb0: flags=4163<UP,BROADCAST,RUNNING,MULTICAST>  mtu 1500
        inet 10.42.0.1  netmask 255.255.255.0  broadcast 10.42.0.255
        inet6 fe80::ca90:cdff:661a:3b51  prefixlen 64  scopeid 0x20<link>
        ether ce:93:72:f0:1d:b5  txqueuelen 1000  (Ethernet)
        RX packets 71  bytes 9285 (9.2 KB)
        RX errors 0  dropped 0  overruns 0  frame 0
        TX packets 28  bytes 6076 (6.0 KB)
        TX errors 0  dropped 0 overruns 0  carrier 0  collisions 0

wlp0s20f3: flags=4163<UP,BROADCAST,RUNNING,MULTICAST>  mtu 1500
        inet 192.168.68.108  netmask 255.255.255.0  broadcast 192.168.68.255
        inet6 fe80::a01c:ead2:ff24:cb60  prefixlen 64  scopeid 0x20<link>
        ether 04:ea:56:25:15:2f  txqueuelen 1000  (Ethernet)
        RX packets 54791  bytes 53663661 (53.6 MB)
        RX errors 0  dropped 207  overruns 0  frame 0
        TX packets 34576  bytes 8087141 (8.0 MB)
        TX errors 0  dropped 0 overruns 0  carrier 0  collisions 0

I read the README-usb-dev-mode.txt and proceeded to change the Ethernet interface’s address and etc. as follows:

jmescarro@jmescarro-System-Product-Name:~$ nmcli device 
DEVICE             TYPE      STATE         CONNECTION         
enxee586d880382    ethernet  connected     Wired connection 2 
usb0               ethernet  connected     Wired connection 3 
wlp0s20f3          wifi      connected     CASSIETHETOYPOODLE 
docker0            bridge    connected     docker0            
p2p-dev-wlp0s20f3  wifi-p2p  disconnected  --                 
enp6s0             ethernet  unavailable   --                 
lo                 loopback  unmanaged     --                 
jmescarro@jmescarro-System-Product-Name:~$ nmcli device show enxee586d880382
GENERAL.DEVICE:                         enxee586d880382
GENERAL.TYPE:                           ethernet
GENERAL.HWADDR:                         EE:58:6D:88:03:82
GENERAL.MTU:                            1500
GENERAL.STATE:                          100 (connected)
GENERAL.CONNECTION:                     Wired connection 2
GENERAL.CON-PATH:                       /org/freedesktop/NetworkManager/ActiveConnection/18
WIRED-PROPERTIES.CARRIER:               on
IP4.ADDRESS[1]:                         10.42.1.1/24
IP4.GATEWAY:                            --
IP4.ROUTE[1]:                           dst = 10.42.1.0/24, nh = 0.0.0.0, mt = 101
IP6.ADDRESS[1]:                         fe80::550:1a43:93a8:5d3a/64
IP6.GATEWAY:                            --
IP6.ROUTE[1]:                           dst = fe80::/64, nh = ::, mt = 101
jmescarro@jmescarro-System-Product-Name:~$ sudo nmcli connection modify "Wired connection 2" ipv4.addresses 192.168.55.100/24 ipv4.method manual
jmescarro@jmescarro-System-Product-Name:~$ sudo nmcli connection up "Wired connection 2"
Connection successfully activated (D-Bus active path: /org/freedesktop/NetworkManager/ActiveConnection/19)
jmescarro@jmescarro-System-Product-Name:~$ sudo iptables -t nat -A POSTROUTING -o enxee586d880382 -j SNAT --to  192.168.55.100
jmescarro@jmescarro-System-Product-Name:~$ ping 192.168.55.1
PING 192.168.55.1 (192.168.55.1) 56(84) bytes of data.
64 bytes from 192.168.55.1: icmp_seq=1 ttl=64 time=2.04 ms
64 bytes from 192.168.55.1: icmp_seq=2 ttl=64 time=2.30 ms
64 bytes from 192.168.55.1: icmp_seq=3 ttl=64 time=2.69 ms
64 bytes from 192.168.55.1: icmp_seq=4 ttl=64 time=2.63 ms
^C
--- 192.168.55.1 ping statistics ---
4 packets transmitted, 4 received, 0% packet loss, time 3005ms
rtt min/avg/max/mdev = 2.040/2.416/2.692/0.264 ms

As per instruction in the readme file I had manually changed the IP address of my Ethernet connection from host to Jetson Orin Nano and also enabled NAT. Evidently, I can ping the device. However, I still cannot SSH and it gives the same ssh: connect to host 192.168.55.1 port 22: Connection refused response.

I’m not sure if this helps, but:

jmescarro@jmescarro-System-Product-Name:~$ arp -a 192.168.55.1
? (192.168.55.1) at ee:58:6d:88:03:81 [ether] on enxee586d880382
jmescarro@jmescarro-System-Product-Name:~$ ssh JMEscarro@192.168.55.1
ssh: connect to host 192.168.55.1 port 22: Connection refused

Another thing that I have gone ahead and done is I have went into the wired connection settings for my Ethernet port (not USB since my setup was over Ethernet) and enabled “Shared to other computers” under both IPv4 and IPv6 settings.

I think I’ve also tried doing those configurations above on the USB port but it couldn’t ping 192.168.55.1.

TL;DR:

  1. Tried the SD card image and balena etcher method but no dice
  2. Flashed JP 5.1.4., appears successful. Tried installing SDK components via SDK manager but things go weird.
  3. Reflashed JP 5.1.4. on device, still cannot SSH nor connect to serial console.
  4. I have tried manually setting address and enabling NAT on Ethernet, did not work.
  5. I have also tried doing the same thing via the USB connection, did not work.
  6. I have enabled network sharing to other computers, still did not work.

I am terribly stumped and am not sure what to do next. Any help would be really nice.

Just replying to a bit in order, I have not completely read this, so this is more or less starting as notes as I read.

It isn’t always obvious, but you can uncheck or check various items in JetPack/SDK Manager. It is perfectly ok to uncheck flash and install of software to a host PC, etc… You can later perform any non-flash operation without flashing again. The trick is that when that extra software is installed the Jetson must be fully booted and have the admin account ready (such as completing first boot login account setup). You can then use the IP address of the virtual USB ethernet, or any other IP address, such as the wired ethernet (the default tries to use the virtual wired ethernet address of 192.168.55.1). Just uncheck other items, boot the Jetson, and go.

Having a monitor does simplify things, but is not necessary.

Virtual wired ethernet does not depend on a GUI, nor does it depend on Wi-Fi. It is Wi-Fi which Linux and Ubuntu tries to tie to the user’s GUI login, and so everything else should work. This includes 192.168.55.1 (try pinging it from the host PC), and if wired ethernet is plugged in to the same router, then it also includes whatever address the router uses. Serial console cannot be used for this, but can be quite useful in finding out what address the wired ethernet has. Or setting up an address.

Just to reiterate, serial console should work even when much of the system is failing. If you can log in via serial console (which can complete first boot account setup), then you are good to go. If serial console does not work, then some debugging is in order. You might be interested in this:

Note that several generations of Nano use the same serial console and carrier board layout. There are multiple serial UARTs, but only one is the serial console. When UARTs with individual wires are used they require a 3.3V logic level. Some Jetsons have a micro-OTG serial port which uses USB for this function (internally it meets the 3.3V requirement and you no longer need a serial UART cable; this becomes an ordinary micro-B USB cable). Third party commercial carrier boards might be the same, but often will differ.

Serial UARTs are very common, simple, and useful, and so you will have some UART headers which are unrelated to serial console.

USB-C is used for flash, and I do not have an Orin Nano to look at, but this tends to be for flash and not for serial console (it could be used with serial console if configured and wired correctly, but I do not know of this being the case).

You basically have to know about the L4T release from where you download the software. If you have a host PC, and you now have directory “~/nvidia/nvidia_sdk/JetPack_...version.../Linux_for_Tegra/”, then the “version” tells you the JetPack release. JetPack 5.x corresponds to L4T R35.x, and JetPack 6.x corresponds to L4T R36.x. For more detailed information you would go to “Linux_for_Tegra/rootfs/etc/”, and check the content of the nv_tegra_release file. If you have already used cd to go there, then an example is:
head -n 1 nv_tegra_release

On a Jetson which is up and running (which yours is not, but I’m adding this for completeness), one would check the “/etc/nv_tegra_release” there. You can plug in an SD card and mount the partition, and check the nv_tegra_release on the SD card as well.


Now moving on to reply to the later reply…

So far as getting stuck goes, are you using a VM? USB often gets stuck when a VM loses USB. If not, then you can try to simply unplug and replug the USB cable to get it started. For a dev kit you would want to perform a QSPI flash to the Jetson (for which the Jetson is connected via the USB cable). The SD card can be created with Balena Etcher separately. I think you’d have to figure out the part where it stalls at 99% before you could continue.

Flashing the Jetson itself always requires recovery mode. During flash the Jetson does reboot if flash is successful, and this is when optional software is added without being in recovery mode. However, when it gets stuck at 99%, then it means you still need recovery mode.

Incidentally, the fan going on briefly and then off is normal. This is because the Jetson uses such little power and produces almost no heat that the fan can turn off. Under a heavy load the fan would turn on.

USB might seem to be detected either when fully booted or in recovery mode. If fully booted though, this only works if the system is up and running, which is when the wired virtual ethernet shows up. If not fully booted and running the virtual wired ethernet, then USB would most likely not be detected (there are a couple of virtual devices, and normally they all work or all fail). Flash always works only in recovery mode (such as QSPI flash of the module). Adding optional software is always from a fully booted Jetson which is not in recovery mode.

One trick for figuring out a serial console or many other devices: First monitor “dmesg --follow”. Then plug in or replug the particular USB device and see what log lines appear. Part of those log lines would note if USB saw the device change, and the rest would be related to a driver binding to the device. This is a wonderful tool for figuring out USB issues.

When a particular brand of serial UART USB cable is plugged in you will see a note of USB connecting. Then there will be a note of description of the device. Following this, there would be a note of creating the “/dev/ttyACM#” device special file. That file is not a real file, but is actually part of the driver, and lives in RAM; the existence of that file says that not only did USB function correctly, but also that the chipset of the device has a working driver that recognized this and bound to the USB device. If this no longer shows up, then it is likely because the device is one of the following:

  • Not powered.
  • Has a USB issue.
  • Perhaps a driver no longer exists.

Basically, see what the “dmesg --follow” says. Sometimes a USB cable is of low quality and fails, but I’ve not seen that with a USB-C cable. In the case of a micro-OTG cable, a lot of “charger cables” fail due to quality issues. A separate USB serial UART cable would normally work well if the cable is correctly set with a 3.3V logic level.

Which computer is the ifconfig from? I’m guessing it is from the host PC. If the virtual wired ethernet device on the Jetson was seen by the host PC, then the host PC would have had one interface with IP address 192.168.55.100. The host PC would be able to ping itself with “ping 192.168.55.100”, and the Jetson could be pinged with “ping 192.168.55.1”. This would prove the Jetson was functional and fully booted (there could still be ssh issues). One of the same debugging tips here is to monitor “dmesg --follow” on the host PC, and then unplug/replug the relevant USB connector and see what it says (it is good to copy and paste this “new” logging from the unplug/replug).

I don’t know if you have changed addresses of the Jetson. Is the nmcli from the host PC? The virtual wired device probably won’t allow changing it through nmcli, it isn’t a “real” device, and the software interface is somewhat limited. However, the success of the ping 192.168.55.1 tends to say it is working (you probably got this part right even though I haven’t seen someone change it this way).

Now the part that must work is ssh if we are talking about installing optional software (flash is only in recovery mode; ssh and networking are not up when in recovery mode). The ssh failure seems to be an account setup issue, or else the ssh daemon is not running. Because the connection is refused, I’m thinking that the daemon is not running. When the daemon is running, and when security allows it at the host PC side, then you could connect even if the login attempt is rejected. The lack of connection means it failed before a login attempt was ever reached. I would bet that it never got to the point where a first boot account setup was available. A more poetic description is that what you’ve described is that “the lights are on, but nobody is home”.

Can you verify:

  • The SD card image was from JP 5.1.4? This is L4T R35.x.
  • Can you get flash of the actual Jetson to complete? If this gets stuck at 99%, then the QSPI never completed flash.

Hey there, I appreciate this response. This will be a quick reply from me however as I’m borrowing an HDMI monitor and don’t have much time.

I have yet to look into UARTs. It might be that I’m hoping to connect the device to serial console through solely USB-C or Ethernet (I’m not sure which, so I might be the one at fault here and I probably need a special cable to connect to serial console)

As for L4T release both match and have R35 (both on SD-Card, assuming SD on Jetson Orin Nano is L4T-Tegra, and on the host PC) as seen here:

This isn’t a VM. I am booting the Ubuntu OS on my laptop via an external HDD.

To clarify, the 99% stuck only occurs flashing Jetpack 6 in Nvidia SDK Manager. Tried this using Ubuntu 22.04 system, booted from the same External HDD (partitioned for Ubuntu 20.04 and 22.04) and failed. I assume because there needs to be additional setup for JP 6.0 which I wasn’t aware of at the time, so I went for JP 5.1.4. As for JP 5.1.4. flash does seem to always finish. Today I was graced to borrow a friend’s monitor and am currently testing it. It does boot, showing the green Nvidia screen briefly, and then after a while, it turns off, and then monitor says “OUT OF RANGE”. Not sure if this is a related problem.

The USB is detected, as seen above in a previous reply.

I am using a USB-C cable, it is capable of data transfer, after all flash did complete just not sdk component installation (I’ve also used the same cable to transfer files from my phone to my laptop in the past).

You are correct, ifconfig is from the host computer.

I had to change it in that manner as the 192.168.55.100 address was never automatically assigned to the ethernet interface on the host.

Yeah, that would be a pretty accurate description, lights are on but nobody’s home.

Did dmesg --follow and this is what I got (plugging and unplugging):

[11168.049138] rndis_host 1-1:1.0 usb0: unregister 'rndis_host' usb-0000:00:14.0-1, RNDIS device
[11168.173858] cdc_ncm 1-1:1.5 enxee586d880382: unregister 'cdc_ncm' usb-0000:00:14.0-1, CDC NCM
[11173.809666] usb 1-1: new high-speed USB device number 18 using xhci_hcd
[11173.958882] usb 1-1: New USB device found, idVendor=0955, idProduct=7020, bcdDevice= 0.02
[11173.958896] usb 1-1: New USB device strings: Mfr=1, Product=2, SerialNumber=3
[11173.958902] usb 1-1: Product: Linux for Tegra
[11173.958908] usb 1-1: Manufacturer: NVIDIA
[11173.958912] usb 1-1: SerialNumber: 1422424336270
[11173.968138] rndis_host 1-1:1.0 usb0: register 'rndis_host' at usb-0000:00:14.0-1, RNDIS device, ce:d7:a1:4d:c3:f7
[11173.969597] cdc_acm 1-1:1.2: ttyACM0: USB ACM device
[11173.970334] usb-storage 1-1:1.4: USB Mass Storage device detected
[11173.970674] scsi host5: usb-storage 1-1:1.4
[11174.003138] cdc_ncm 1-1:1.5: MAC-Address: ee:58:6d:88:03:82
[11174.003441] cdc_ncm 1-1:1.5 usb1: register 'cdc_ncm' at usb-0000:00:14.0-1, CDC NCM, ee:58:6d:88:03:82
[11174.037514] cdc_ncm 1-1:1.5 enxee586d880382: renamed from usb1
[11174.253043] IPv6: ADDRCONF(NETDEV_CHANGE): enxee586d880382: link becomes ready
[11175.002526] scsi 5:0:0:0: Direct-Access     Linux    File-Stor Gadget 0510 PQ: 0 ANSI: 2
[11175.003299] sd 5:0:0:0: Attached scsi generic sg2 type 0
[11175.004412] sd 5:0:0:0: Power-on or device reset occurred
[11175.005593] sd 5:0:0:0: [sdc] 32768 512-byte logical blocks: (16.8 MB/16.0 MiB)
[11175.006131] sd 5:0:0:0: [sdc] Write Protect is on
[11175.006140] sd 5:0:0:0: [sdc] Mode Sense: 0f 00 80 00
[11175.006680] sd 5:0:0:0: [sdc] Write cache: disabled, read cache: enabled, doesn't support DPO or FUA
[11175.011680]  sdc:
[11175.013101] sd 5:0:0:0: [sdc] Attached SCSI removable disk
[11263.609318] usb 1-1: USB disconnect, device number 18
[11263.609558] rndis_host 1-1:1.0 usb0: unregister 'rndis_host' usb-0000:00:14.0-1, RNDIS device
[11263.750127] cdc_ncm 1-1:1.5 enxee586d880382: unregister 'cdc_ncm' usb-0000:00:14.0-1, CDC NCM

Flash does complete, just no SDK component installation. Also no serial console, and no SSH. With the monitor as of now, it displays OUT OF RANGE before reaching initial setup. The monitor is a 1920x1080 60FPS HDMI, and I’m using DP-HDMI converter (I assume this would be a passive adapter since it’s quite thin.

I’ll keep this forum post updated still and I’ll continue to troubleshoot things. I still need help as I can’t get beyond initial setup, and the monitor I borrowed I need to return today too.

Since my last update a lot of weird things have been happening.

While I was away, the monitor had sputtered into life, but it was not the screen I was expecting.

I enabled wired network connections since it seemed disabled for some reason in the top right. Notably, I still couldn’t ssh nor serial into the device…

So I let it do its thing. It was incredibly slow and sluggish which was very unusual. Here’s what happened:

It then rebooted… Flashing this:

Here’s a clearer picture of the message that flashed. Note that when it turned off, it would display “OUT OF RANGE”.

In this entire ordeal I was never able to ssh or serial. It rebooted 4 times before entering a recovery mode, where it got stuck in an “OUT OF RANGE” screen.

I am aware that at this point, the issue may have deviated significantly from what I first posted it as, being a “Cannot SSH” problem, but I would like to document everything thus far in the hopes that if somebody comes across the same problems, they might find a solution here.

I’m posting on my phone right now, and I’ll soon hop on my laptop to edit this and include the SDK log files and the dmesg --follow outputs during the weird installation thing.

Edit: Here’s the logs and the output of dmesg --followon host device during the entire thing:

Logs:
SDKM_logs_2025-01-09_13-56-10.zip (212.7 KB)

dmesg --follow:

[12347.227018] cdc_ncm 1-1:1.5 enxee586d880382: unregister 'cdc_ncm' usb-0000:00:14.0-1, CDC NCM
[12347.578840] usb 1-1: new high-speed USB device number 21 using xhci_hcd
[12383.418694] usb 1-1: new high-speed USB device number 22 using xhci_hcd
[12383.567972] usb 1-1: New USB device found, idVendor=0955, idProduct=7020, bcdDevice= 0.02
[12383.567986] usb 1-1: New USB device strings: Mfr=1, Product=2, SerialNumber=3
[12383.567993] usb 1-1: Product: Linux for Tegra
[12383.567999] usb 1-1: Manufacturer: NVIDIA
[12383.568006] usb 1-1: SerialNumber: 1422424336270
[12383.575056] rndis_host 1-1:1.0 usb0: register 'rndis_host' at usb-0000:00:14.0-1, RNDIS device, 42:5d:be:ad:dc:55
[12383.576742] cdc_acm 1-1:1.2: ttyACM0: USB ACM device
[12383.584150] usb-storage 1-1:1.4: USB Mass Storage device detected
[12383.584736] scsi host5: usb-storage 1-1:1.4
[12383.613061] cdc_ncm 1-1:1.5: MAC-Address: ee:58:6d:88:03:82
[12383.613454] cdc_ncm 1-1:1.5 usb1: register 'cdc_ncm' at usb-0000:00:14.0-1, CDC NCM, ee:58:6d:88:03:82
[12383.646542] cdc_ncm 1-1:1.5 enxee586d880382: renamed from usb1
[12383.856246] IPv6: ADDRCONF(NETDEV_CHANGE): enxee586d880382: link becomes ready
[12384.599796] scsi 5:0:0:0: Direct-Access     Linux    File-Stor Gadget 0510 PQ: 0 ANSI: 2
[12384.600396] sd 5:0:0:0: Attached scsi generic sg2 type 0
[12384.601384] sd 5:0:0:0: Power-on or device reset occurred
[12384.602515] sd 5:0:0:0: [sdc] 32768 512-byte logical blocks: (16.8 MB/16.0 MiB)
[12384.603063] sd 5:0:0:0: [sdc] Write Protect is on
[12384.603074] sd 5:0:0:0: [sdc] Mode Sense: 0f 00 80 00
[12384.604078] sd 5:0:0:0: [sdc] Write cache: disabled, read cache: enabled, doesn't support DPO or FUA
[12384.607328]  sdc:
[12384.608602] sd 5:0:0:0: [sdc] Attached SCSI removable disk
[13112.268389] perf: interrupt took too long (2533 > 2500), lowering kernel.perf_event_max_sample_rate to 78750
[13210.973620] usb 1-4: USB disconnect, device number 20
[13232.203507] usb 1-4: new full-speed USB device number 23 using xhci_hcd
[13232.335628] usb 1-4: device descriptor read/64, error -71
[13232.594921] usb 1-4: New USB device found, idVendor=260d, idProduct=1026, bcdDevice= 3.00
[13232.594935] usb 1-4: New USB device strings: Mfr=1, Product=2, SerialNumber=0
[13232.594942] usb 1-4: Product: 2.4G Wireless Receiver
[13232.594947] usb 1-4: Manufacturer: Compx
[13232.601350] input: Compx 2.4G Wireless Receiver as /devices/pci0000:00/0000:00:14.0/usb1/1-4/1-4:1.0/0003:260D:1026.0008/input/input33
[13232.602060] hid-generic 0003:260D:1026.0008: input,hidraw1: USB HID v1.10 Mouse [Compx 2.4G Wireless Receiver] on usb-0000:00:14.0-4/input0
[13232.606641] input: Compx 2.4G Wireless Receiver Keyboard as /devices/pci0000:00/0000:00:14.0/usb1/1-4/1-4:1.1/0003:260D:1026.0009/input/input34
[13232.663938] input: Compx 2.4G Wireless Receiver as /devices/pci0000:00/0000:00:14.0/usb1/1-4/1-4:1.1/0003:260D:1026.0009/input/input35
[13232.664237] input: Compx 2.4G Wireless Receiver as /devices/pci0000:00/0000:00:14.0/usb1/1-4/1-4:1.1/0003:260D:1026.0009/input/input36
[13232.664832] hid-generic 0003:260D:1026.0009: input,hiddev0,hidraw2: USB HID v1.10 Keyboard [Compx 2.4G Wireless Receiver] on usb-0000:00:14.0-4/input1
[13240.687962] usb 1-4: reset full-speed USB device number 23 using xhci_hcd
[13240.815597] usb 1-4: device descriptor read/64, error -71
[13241.051619] usb 1-4: device descriptor read/64, error -71
[13241.287643] usb 1-4: reset full-speed USB device number 23 using xhci_hcd
[13241.419666] usb 1-4: device descriptor read/64, error -71
[13241.655643] usb 1-4: device descriptor read/64, error -71
[13241.899569] usb 1-4: reset full-speed USB device number 23 using xhci_hcd
[13241.899754] usb 1-4: Device not responding to setup address.
[13242.107745] usb 1-4: Device not responding to setup address.
[13242.315558] usb 1-4: device not accepting address 23, error -71
[13242.443602] usb 1-4: reset full-speed USB device number 23 using xhci_hcd
[13242.443807] usb 1-4: Device not responding to setup address.
[13242.655781] usb 1-4: Device not responding to setup address.
[13242.863560] usb 1-4: device not accepting address 23, error -71
[13242.863668] usb 1-4: USB disconnect, device number 23
[13243.179527] usb 1-4: new full-speed USB device number 24 using xhci_hcd
[13243.307613] usb 1-4: device descriptor read/64, error -71
[13243.543571] usb 1-4: device descriptor read/64, error -71
[13243.787564] usb 1-4: new full-speed USB device number 25 using xhci_hcd
[13243.919575] usb 1-4: device descriptor read/64, error -71
[13244.155627] usb 1-4: device descriptor read/64, error -71
[13244.263629] usb usb1-port4: attempt power cycle
[13244.923565] usb 1-4: new full-speed USB device number 26 using xhci_hcd
[13244.923735] usb 1-4: Device not responding to setup address.
[13245.135709] usb 1-4: Device not responding to setup address.
[13245.343577] usb 1-4: device not accepting address 26, error -71
[13245.471582] usb 1-4: new full-speed USB device number 27 using xhci_hcd
[13245.471772] usb 1-4: Device not responding to setup address.
[13245.679723] usb 1-4: Device not responding to setup address.
[13245.887549] usb 1-4: device not accepting address 27, error -71
[13245.887689] usb usb1-port4: unable to enumerate USB device
[14539.989282] Lockdown: systemd-logind: hibernation is restricted; see man kernel_lockdown.7
[14550.018571] nouveau 0000:01:00.0: Enabling HDA controller
[15736.677106] usb 1-1: USB disconnect, device number 22
[15736.677295] rndis_host 1-1:1.0 usb0: unregister 'rndis_host' usb-0000:00:14.0-1, RNDIS device
[15736.839586] cdc_ncm 1-1:1.5 enxee586d880382: unregister 'cdc_ncm' usb-0000:00:14.0-1, CDC NCM

For reference of other people reading this, both SD card and JetPack are for L4T R36.6.0.

On the laptop, is the media used in flashing on an ext4 formatted partition? You can cd to the Linux_for_Tegra/ directory and run this command:
df -H -T .
(if not ext4, then the result for any content on the SD card will fail, but you won’t know it until boot)

For the monitor, is it an HDMI monitor? Or DisplayPort? If there is any kind of adapter for VGA it will fail; if there is an adapter for DVI, and if it is analog (there is also a digital DVI-D), then this too will fail. I am surprised to hear about the “out of range” if this is a digital connection (old VGA is analog, so is any DVI other than DVI-D).

Have you ever made it to the first boot login? There is an alternative if this part is the problem. The alternative: If you cd to the “Linux_for_Tegra/” directory on the host (laptop), and if you have mounted the SD card’s rootfs partition on “Linux_for_Tegra/rootfs/”, you can then run this command to set this up from the host:
sudo ./tools/lvt_create_default_user.sh
…and this will update the admin account on the SD card, along with completing all of the first boot setup. Do keep in mind that unless the SD card partition is ext4 that this will probably be an issue.

Note: Be careful to properly umount the SD card from the host PC if you do this. Don’t pull the SD out while it is mounted.

Maybe someone from NVIDIA can comment if there are other partition types that SD cards can have, e.g., exFAT, but I think those are all asking for trouble.

Incidentally, either Ubuntu 20.04 or 22.04 should work on JetPack 6 or JetPack 5. Many of the requirements are due to the host PC creating content for an Ubuntu Jetson install (remember that L4T is just Ubuntu plus NVIDIA drivers).

The USB-C should be ok to use. You can still unplug and replug the USB-C if it gets stuck, and this might allow continuing. If not, then you might try a different port. Maybe @WayneWWW or @DaveYYY or @KevinFFF could look at the log you attached to the previous post, but be sure to comment on my above questions. So far as I can see in the dmesg there is a USB error (possibly signal related, but I cannot say for certain). This latter could change if you change the USB connection itself; some examples are to use a different port; to remove a HUB if there is a HUB between; to add a HUB if no HUB (the goal is to change the USB and perhaps the new path will not have this error).

Hello, terribly sorry for the late response. My SD Card was in exFAT and I’m currently formatting it as ext4. Without your response, I would’ve never known that ext4 is the appropriate format for Linux systems. I’ll update if this works, and I’ll also proceed to answer your other questions once I accomplish formatting and reflashing.

Edit: It’s been a couple of hours now and it seems my SD card was damaged too, I’ll post a proper reply when I get my hands on a fresh SD card.

The reason why non-Linux filesystem types are a problem is that they cannot handle the full *NIX/Linux permissions. In the case of “set UID root” (SUID) not being valid, everything related to sudo is denied. The command “sudo” itself is needed for many operations, and lack of suid on that command means sudo will always be denied. I suppose a specially recompiled set of security files could use a Windows filesystem type. So far as data goes though, other filesystem types would work (which is why install succeeds without warning).

It would be interesting for NVIDIA to add any comment on anything special about formatting of the SD card.

Bought a new SD card and immediately formatted the partition to ext4 and I’m happy to say that this worked like a charm!

Though everything is installing and the Jetson Orin Nano had already booted to life, I do think (well, I hope) that everything is fine.

Thanks @linuxdev, I would’ve never figured this out on my own.

Edit: I still had to do the manual changes I mentioned in the beginning of this post on the host computer’s Ethernet interface, as well as manually enable ssh on the Jetson Orin Nano which I was able to do via serial console. The difference is this time, I’m able to access the serial console since the Orin Nano was able to get past initial set-up.

Edit 2: Installation completed and the Jetson Orin Nano is up and running :)