I’m using the SDKManger 1.4.1.7402 to flash the Jetson Xavier with Jetpack 4.5 (or 4.5.1).
The host is a Ubuntu 18, and the Jetson is connected to a keyboard and a monitor.
After the Ubuntu configuration (language, keyboard, username/password, the “mode 15W desktop” setting) I see the progress bar for the configuration… and nothing happens. I think it’s Ubuntu’s login screen, but without the login fields.
If I go on the tty1 terminal I see “please complete system configuration setup on desktop to proceed”. If I go on te tty2 terminal, I can actually log in. I do not see anything special with dmesg.
On the host side, I cannot continue the procedure with SSH.
I cannot software-shutdown the Jetson cleanly since I cannot use sudo. After a hardware-restart I have to start all over again (language/keyboard/etc…), but this time it remembers my previous setting for the language and keyboard.
Note that it’s not my first flashing and don’t remember having any problem.
Connect your ubuntu host to the jetson xavier through the flash port/cable. Open /dev/ttyACM0 on your host side with minicom. And it will give you a headless configuration to finish this “system configuration”.
I don’t get anything but a blank screen with minicom -D /dev/ttyACM0
(also tried `gtkterm)
Other things I tried that did not work:
updating the SDKManager
powering off properly with systemctl poweroff as it doesn’t ask for sudo. BTW, I find it weird that I cannot sudo, is it normal I still cannot do it at this stage?
Also I forgot to mention it, but this Xavier DevKit comes from a RMA process. Could it be the reason for my problem?
I tried the minicom command several times, waiting waited up to 5min, and I did so right after the flashing then at the frozen login screen then after rebooting… and nothing appeared on the terminal.
The ttyACM0 device is here: it appears as soon as the flashing is over. Also when I reboot, minicom gives me a disconnection warning so I guess the connection is on.
Do you see anything else I can try? I can use the tty2 terminal on Ubuntu (but cannot sudo).
I don’t guarantee this would still make system work normally or not. But at least you can bypass the system configuration. Also, I would like to check your log after your setup is done.
Is this a folder I should see in the Ubuntu host? I only see a “L4T_README” and the corresponding drive is mounted with the ro (read only) flag and I cannot write anything to it even with sudo.
For the logs, my only solution would be to put them on a USB key, however I do not have any USB-A hub at this moment, so the only USB-A plug available is for the keyboard. I can have the hub on Tuesday.
Linux_for_Tegra is the driver package that downloaded by sdkmanager. Sdkmanager is just a GUI tool but the core function is still the Linux_for_Tegra. Search your host computer and you shall find it. The default path should be ~/nvidia if your sdkmanager downloads it correctly.
I’m pretty sure I’ve found out what the problem was. I didn’t have enough disk space on my main Linux (ext4) partition to download the package and prepare the L4T image, so I used my Windows (ntfs) data partition.
I found out how to free a lot of space (it was docker…) so I tried using the main Linux drive to prepare the L4T image and the installation worked!
Extra tips for noobs: I had first “uninstall” the L4T image on my Windows partition in order to change the location, and did so clicking the “repair/uninstall” tool in Step 1 of the SDKManager.
Since I’m sure many people use a dual boot system with quite a greedy partitioning for Linux, here’s a potential trick (haven’t tried it) when disk space is insufficient: using an ext4 formatted USB key (or external drive) to prepare the L4T image would preserve the exact files/folders permissions and avoid the install problem seen with (Windows) ntfs partitions.
Can confirm I had the same issue here and fixed it by installing from a host with more free diskspace. Would be great if you could include a check whether there is enough free space before starting the install!