After some days trying to flash my Xavier I’m stuck as it repeatably stops while in the process of flashing the Jetson OS to my new Xavier. I’ve spent some time on this forum reading through, mostly unstructured ideas, but could not find the exact root-cause. The Python was demoted as per some hints including the unzip. it seems the USB connection goes into sleep after some time during the flashing. the lsusb instructions supports that. I’ve noticed that WayneWWW @nVidia suggested building it with Jetpack4.1.1 before installing the latest Jetpack. Are there any routines to control the accessibility of the USB port during the process?
Demoting Python & unzip done on the host not on the target.
Note that you can dual install both python 2 and 3…you don’t actually have to remove 3.
The USB purposely disconnects and reconnects during the flash process. VMs don’t handle that correctly, but a regular Ubuntu install will handle the disconnect/reconnect (the behavior is not a bug).
Once flash is complete and the Xavier reboots sleep is a possible issue, but should not be an issue right after a boot. If it turns out that after first boot the Xavier is running package updates, then you might be locked out of doing your own package installs until that completes. That completion might take long enough for sleep to occur. Prior to any of this starting, if using JetPack4.2, you must manually log in once to the rebooted Xavier to create a login account, and so if you don’t have a keyboard/monitor attached during the flash, then you might miss the first login account creation. If there is no account creation, then ssh is not possible and even if the Xavier finishes package updates, then you still will not be able to connect to continue package installs…which would result in auto-suspend of USB for energy savings.
Can you verify if the issue is after flash completes and package install is started? Or if this is during actual flash? Can you verify first boot creation of the admin login account?
Ubuntu runs on an Ubuntu certified NUC7i7DNHE with 16G ram and SSD. I’ll use screens and keyboards for Host and Target for next try.
Flash was not fully completed it stopped at around 45-50% while flashing Jetson OS( started at 40% of completion reporting). Observed this around 10 retry’s.
I have heard of one NUC which didn’t work correctly, but I don’t know the reason why that occurred. I personally did not see anything in the NUC’s specs to say it wouldn’t work. Is it possible the NUC itself is putting the USB port to sleep after some time idle? If you monitor “dmesg --follow” during the flash, is there any message near the time of the USB failure?
Having both host and target connected to the same LAN and both having a monitor and keyboard is an prerequisite to flash the target to provide login details at both during the process.