Nothing on boot.

I recently got a replacement Jetson TX1, and upon booting it up for the first time, it showed up on the network, but attempting to SSH into it just got a connection reset. After that, I flashed it with l4t 24.2. Nothing. And again with l4t 23.1. Nothing. The only thing that happens after flashing and reseting is both Ethernet LEDs being lit up.

If there is any way you can try a serial console this would be the best way to see what is going on (serial console is immune to many failures). Here’s some serial console info:
http://elinux.org/Jetson/TX1_Serial_Console

Seeing a log of the flash would help too (there is one really really long line where it gives percent completion of sending the root partition…what looks like a changing percent in console is really a single line that backspaces and overwrites…the log gets about a megabyte of percent progress). For example:

sudo ./flash.sh -S 14580MiB jetson-tx1 mmcblk0p1 2>&1 | tee flash_log.txt

You’d probably want to find that really really long line (turn off line wrap in your editor if possible) and remove that first if it reaches there.

Also, is there anything special about the host, e.g., is it a VM?

Host is a a regular desktop, running openSUSE tumbleweed.
Log is available at https://a.pomf.cat/dnhped.txt
I’m not sure what I can do about the serial console right now though.

(ROFL, I like the “Vim FTW!” in the flash log…I also use vim for many situations…I really like the ability to edit out that long line in the flash log with vim better than any other editor).

The log shows flash was 100% successful, and the Jetson should be functioning correctly so far as the flash is concerned. The ssh issue has to be firewall and/or DHCP issues from outside of the Jetson (the Jetson does not firewall ssh). Most hosts do not firewall outgoing ssh, so I doubt your openSUSE host interferes even if it does have a firewall set up (you could double check just to be sure).

I would start by finding whichever device is used as the DHCP server and checking logs. If you use the openSUSE host to provide DHCP, then either dmesg or one of the “/var/log/” files would show what address is and any sort of error message. In the case of a router there is usually a web access to the router to see its logs. If an outside router is involved, then it is possible the router is filtering ssh. Even if the DHCP is provided by the openSUSE host, and even if DHCP is successful, it is possible that any kind of discrete router or firewall-capable managed switch would block ssh.

So far as physical cabling goes, what kind of network switch and/or router is involved? Is DHCP itself provided by host or via router? Does a simple ping work?

DHCP is provided by the router, and with an arp-scan, it doesn’t show up on the network.

I’m not sure how a JetPack install deals with routers versus providing DHCP on a desktop host, but the Jetson itself will use a fairly standard DHCP request. Do you have any direct access to the Jetson where you might be able to see the output of “ifconfig”? Do you have a web interface to your router to see what it is logging?

It seems like one of the biggest network issues (so far as I’ve seen) with Ubuntu (and anything using NetworkManager to configure…the NetworkManager auto configuration irritations extend to any Linux machine) is a mess with wireless wlan0 where even if you don’t want wireless it tends to cause wired to fail. I’m also wondering if perhaps there is a wireless network somewhere which your Jetson is logging in to, and thus resulting in wired being disabled…if nm thinks wireless is active it may be causing wired to directly or indirectly get disabled.

I don’t have video, or any sort of console.

Do you have access to your router’s logging? A serial console might be necessary if you have no regular local access and networking is also down. The logs showed flash was good, so I strongly suspect there is just a network setup issue (either the router is filtering or the Jetson is stuck on trying to use WiFi when it should use only wired).