JetPack 4.4 headless setup broken

As describe in headless initial configuration: looking for password, I don’t know if nVidia is aware of this problem installing image nv-jetson-nano-sd-card-image-r32.4.2.zip.

Sorry for creating a new topic, but it seems nvidia is not aware of the problem.

When connecting the USB, I can see L4TREADME appearing, then tty disconnect, when it comes accessible again, I see a login screen with localdomain.

Thanks

HI tvai,

What is the exact problem you meet? According to the description, I am not very sure what is going one.
Please describe the scenario more clearly. For example, what USB? the micro usb port? Is this the first boot up?

Well, with r32.3.1, after recording the image with etcher, I plugged it and connected the micro USB to my PC.
I could see the device /dev/ttyACM0 and connect to it via screen. Then the license etc etc, everything OK.

With r32.4.2, impossible, I see a few seconds the license, then it disconnects, does something for some seconds maybe a minute, and seems to reboot, and then I see the login screen. I did it 5 times and all the times it happened the same.

It seems to be this problem: headless initial configuration: looking for password
but the guy at the end went back to an old version, and did an update.

I can do any test if you want more information.

thanks

1 Like

With r32.4.2, impossible, I see a few seconds the license, then it disconnects, does something for some seconds maybe a minute, and seems to reboot, and then I see the login screen. I did it 5 times and all the times it happened the same.

You mean the setup somehow finishes automatically, didn’t ask your input and directly goes into the login prompt so you don’t know the password at all?

Does this issue only happen to sdcard image? I mean if you use the sdkmanager, would you hit this issue?

This is exactly what I mean, yes with SD card, it seems to do the installation but without asking me for input.
I just could see the license screen, but it did not give me the chance to interact with the screen.
I 've not tried with the SDKManager yet, I’ll try it and let you know.

I guess you can reproduce it easily with SD card and etcher (or dd or whatever):

  • record “nv-jetson-nano-sd-card-image-r32.4.2.zip” to a SD card
  • plug it into the jetson, with J48 and a 4A charger
  • plug micro USB (no ethernet, nor HDMI nor any USB are connected)
  • try connect with screen /dev/ttyACM0 115200

Doing exactly the same steps with “nv-jetson-nano-sd-card-image-r32.3.1.zip” let me interact with the setup screens.

1 Like

Let us check the sdcard image. Please go ahead with sdkmanager first.

Right now I can’t because I’m working with the board, but I’ll let you know later today.

1 Like

Hi tvai,

The oem-config is working on r32.4.2 SDCARD image on Nano.

  1. Using Etcher tool to flash r32.4.2 image on sdcard
  2. Plug-in micro-sd and power jack (J25) and micro-usb (J28) and jumper (J48) on Nano
  3. After power on the device, check host machine:
    $sudo picocom -b 115200 /dev/ttyACM0
    -> start oem-config setting.

Thanks, I will try again, it’s weird because these are the steps I used.
I’ll let you know when I have some time.

Hello,
I have a Jetson Nano and I’m facing the same problem as @tvai
The headless setup using the micro-usb is not working.
The steps that I did were

  1. Downloaded nv-jetson-nano-sd-card-image-r32.4.2.zip (on Windows 10)
  2. Use Balenaetcher to flash the image to a SD card (on Windows 10)
  3. Plug-in micro-sd and power jack (J25) and micro-usb (J28) and jumper (J48) on Nano
  4. Connect USB from Nano to host machine. (on Windows 10)
  5. Launch Putty to communicate with the COM port associated with the Nano. (on Windows 10)
  6. No mesages on the Putty terminal screen (on Windows 10)
    In windows 10 I can see the COM port and the LT4-README drive
    I have also tried to connect to the micro-usb port of the Nano with a Rasperry Pi 4 running Ubuntu and launching screen /dev/ttyACM0 115200 with the same result: No messages displayed on the terminal.

Thanks

Be sure the serial console program is set to speed 115200, 8 bits, no parity, and 1 stop bit. No flow control (no CTS/RTS).

Also, make sure you are using the actual serial device. The name “ttyACM0” is probably specific to Linux, and even then, if you have another serial device, the number part of this may change depending on the order of the serial devices being detected.

Following the instructions of @carolyuu I got it working (on my PC with ubuntu 18.04 desktop) with picocom command. I don’t know if it has something so see with “screen” command, or the order of connecting things…

@linuxdev
Running a Raspberry Pi 4 with Ubuntu 20.04 LTS
Command dmesg shows in the console that the device cdc_acm is ttyACM0, Device ttyACM0 is created when micro-USB from nano is connected.
Executing sudo gtkterm
Connection settings
Port : /dev/ttyACM
Baud Rate: 115200
Parity: None
Bits: 8
Stopbits: 1
Flow control: None

No messages from the Nano displayed for headless setup

Powering off the Nano, powering on
Trying
minicom -b 115200 /dev/ttyACM0
No messages from the Nano displayed for headless setup

Thanks

That should work, at least with minicom/picocom/gtkterm. Do you have ssh access? Or can you at least ping the Nano? It would be useful to find out if the unit is otherwise up and running. If ssh is working, then you could also look at dmesg and examine if nvgetty is running.

@linuxdev
When I power up the nano, the unit does something, at least it creates the virtual drive with access to the L4T-README unit and activates the micro-USB port.
When I plug the ethernet wire, no activity leds on the etherned port…
In the firts run of the nano, after etchin the SD image, is the ethernet port or ssh enabled? If ssh is enabled, what is the user/password?
Thanks

…the above confirms the unit is (at least for basics) running correctly.

After a flash ethernet should run normally when connected to a router/DHCP server. The user/pass is the trick here…there is none unless you completed the first boot setup to create that account. Typically one would do this either locally via monitor/keyboard, or via serial console if headless. Since you are having issues with serial console the implication is that (at least for first boot) you may need to add a monitor/keyboard.

There is an alternate method of adding the admin account/pass if you are flashing from a Linux host (there are all kinds of variations on this, but all run on Linux). See:
https://forums.developer.nvidia.com/t/jetson-nano-all-usb-ports-suddenly-stopped-working/75784/37
…download that script:
https://forums.developer.nvidia.com/uploads/short-url/xMF6uijxdcBfNYWQxDNcQEWEmOJ.gz

What this does is to use QEMU to add the name/pass chroot into the “Linux_for_Tegra/rootfs/etc/...files...”. So you need to run this from the “Linux_for_Tegra/” directory using the same content used for flashing. I have not seen this used with the prepackaged SD card images, but I suspect that if you mount (either actual mount or loopback mount) the rootfs partition of the SD card to the “Linux_for_Tegra/rootfs/” location, then it would work directly on the SD card.

I say "rootfs partition" because the SD card has many partitions. If you are running Linux and monitor “dmesg --follow”, and then insert the SD card to a reader, the particular device should show up. For me this shows as “sdh”. This will very likely differ on your host PC. To see specific partition information you would run:
df -H -T /dev/sdh

Only one partition will show as having a filesystem type (FSTYPE), and that is the rootfs partition. Normally “Linux_for_Tegra/rootfs/” contains that content, but you can mount the actual SD card partition there and run that script and it should work perfectly well just like it would against regular files.

Example if the script is in the “Linux_for_Tegra/” directory (and this exists if you’ve ever used SDK Manager, or if you have manually unpacked the “driver package”…see L4T releases; go there, log in, click link again, find your release).

For R32.4.2 as an example to add just the driver package and not use SDK Manager (if you do not have that content already this is easier):

  1. tar xvfj Tegra210_Linux_R32.4.2_aarch64.tbz2
  2. cd Linux_for_Tegra
  3. sudo mount /dev/sdh1 ./rootfs
  4. # ...copy the script to here...
  5. sudo ./l4t_create_default_user.sh
  6. # ...follow steps...
  7. sudo umount ./rootfs
  8. # ...now try booting with that card, try ssh with the name/pass you added.

If you’ve flashed with SDK Manager before, then probably all of the QEMU content will be present. If not, then you can just add the QEMU content (it’s easy to test, no harm if QEMU is missing).

Hi,
I wanted to use Headless set up because, with the monitors that I have, the resolution that the nano sets when doing the initial setup is too low (I guess is a problem with HDMI and the EDID information or maybe my Nano is faulty).
@linuxdev
I will try to set up ssh as explained above and see.
Thanks

Be careful, if I remember correctly when you plug a HDMI monitor the oem-config is not headless.
I’m not sure about it, but I remember a log message during boot saying something like this “HDMI plugged in, running desktop installation”

Today I wanted to flash an SD card in the same conditions as on Monday, and the problem happened again:

$ sudo picocom -b 115200 /dev/ttyACM0
picocom v2.2

port is        : /dev/ttyACM0
flowcontrol    : none
baudrate is    : 115200
parity is      : none
databits are   : 8
stopbits are   : 1
escape is      : C-a
local echo is  : no
noinit is      : no
noreset is     : no
nolock is      : no
send_cmd is    : sz -vv
System Configuration







        ┌────┤ License For Customer Use of NVIDIA Software ├─────┐
        │                                                        │
        │ Welcome to Jetson Initial Configuration                │
        │                                                        │
        │                         <Ok>                           │
        │                                                        │
        └────────────────────────────────────────────────────────┘








                                                                            
FATAL: term closed
$ sudo picocom -b 115200 /dev/ttyACM0
picocom v2.2

port is        : /dev/ttyACM0
flowcontrol    : none
baudrate is    : 115200
parity is      : none
databits are   : 8
stopbits are   : 1
escape is      : C-a
local echo is  : no
noinit is      : no
noreset is     : no
nolock is      : no
send_cmd is    : sz -vv
receive_cmd is : rz -vv -E
imap is        : 
omap is        : 
emap is        : crcrlf,delbs,

Type [C-a] [C-h] to see available commands

Terminal ready


Login incorrect
localhost.localdomain login: 
Login timed out after 60 seconds.

Ubuntu 18.04.4 LTS localhost.localdomain ttyGS0

localhost login: 

I thought I was too slow to connect the USB cable, so I flahed the SD card again and connected very quickly the USB cable after the power cable, but no luck. In r32.3.1 I would say it didn’t happen even if waiting long time after plugged power in J25.

I’d like to understand why the connection is lost after welcome screen and then it reboots with, of course, no user created.

On Monday, it succeeded following the @carolyuu instructions, but today, no luck.

EDIT1:
I flashed 5 times today the SD card with NO success. I tried another USB cable, another USB port on my PC, invert order of plugging cables (USB vs power), and no luck, I manage to connect with picocom, see the L4TREADME notification on ubuntu, I can see the welcome screen, but if I hit Enter or do nothing, the connection is cut, the nano seems to reboot, and if I reconnect via serial I get the login screen.

EDIT2:
I have more information, I did exactly the same, but I connected a monitor just after seeing L4TREADME notification, to be sure it will be started in headless mode.
Here are the screenshots:


On this step, on the serial console I get the welcome screen, when I hit Enter, I get the following screenshot instantly:




When reached this step, I get the login screen via serial connection

I mounted the SD card on my PC and get the following from the /var/log/oem-config.log:

$ sudo cat /mnt/nano_sd_p1/var/log/oem-config.log

Ubiquity 18.04.14.14 (oem-config)
Ubiquity 18.04.14.14 (oem-config)
/usr/lib/ubiquity/ubiquity/frontend/gtk_ui.py:54: PyGIWarning: Gtk was imported without specifying a version first. Use gi.require_version('Gtk', '3.0') before import to ensure that the right version gets loaded.
from gi.repository import Gtk, Gdk, GObject, GLib, Atk, Gio
/usr/lib/ubiquity/ubiquity/frontend/gtk_components/nmwidgets.py:5: PyGIWarning: NM was imported without specifying a version first. Use gi.require_version('NM', '1.0') before import to ensure that the right version gets loaded.
from gi.repository import NM, NMA
/usr/lib/ubiquity/ubiquity/frontend/gtk_components/nmwidgets.py:5: PyGIWarning: NMA was imported without specifying a version first. Use gi.require_version('NMA', '1.0') before import to ensure that the right version gets loaded.
from gi.repository import NM, NMA
/usr/lib/ubiquity/plugins/ubi-timezone.py:195: PyGIWarning: TimezoneMap was imported without specifying a version first. Use gi.require_version('TimezoneMap', '1.0') before import to ensure that the right version gets loaded.
from gi.repository import TimezoneMap
Failed to play sound: Not available
Ubiquity 18.04.14.14 (oem-config)
debconf_ui selected; starting debconf frontend
Ubiquity 18.04.14.14 (oem-config)
open3: exec of whiptail --backtitle System Configuration --title License For Customer Use of NVIDIA Software --output-fd 12 --nocancel --msgbox License For Customer Use of NVIDIA Software

[VERY LONG LICENSE]

5. EXPIRATION OF TERMINATION OF THIS SUPPLEMENT. Your failure to comply
with the terms of this Supplement is ground for termination for breach
by NVIDIA under the SLA. This Supplement will automatically expire or
terminate upon the expiration or termination of your rights to
VisionWorks Licensed Software under the SLA or this Supplement. --scrolltext 21 76 failed: Argument list too long at /usr/share/perl5/Debconf/FrontEnd/Dialog.pm line 226.
Ubiquity 18.04.14.14 (oem-config)
Traceback (most recent call last):
File "/usr/sbin/oem-config", line 655, in <module>
    main(oem_config)
File "/usr/sbin/oem-config", line 639, in main
    install(args[0], query=options.query)
File "/usr/sbin/oem-config", line 272, in install
    open_terminal()
File "/usr/sbin/oem-config", line 107, in open_terminal
    ttyn = os.ttyname(0)
OSError: [Errno 5] Input/output error
Ubiquity 18.04.14.14 (oem-config)
Traceback (most recent call last):
File "/usr/sbin/oem-config", line 655, in <module>
    main(oem_config)
File "/usr/sbin/oem-config", line 639, in main
    install(args[0], query=options.query)
File "/usr/sbin/oem-config", line 272, in install
    open_terminal()
File "/usr/sbin/oem-config", line 107, in open_terminal
    ttyn = os.ttyname(0)
OSError: [Errno 5] Input/output error
Ubiquity 18.04.14.14 (oem-config)
Traceback (most recent call last):
File "/usr/sbin/oem-config", line 655, in <module>
    main(oem_config)
File "/usr/sbin/oem-config", line 639, in main
    install(args[0], query=options.query)
File "/usr/sbin/oem-config", line 272, in install
    open_terminal()
File "/usr/sbin/oem-config", line 107, in open_terminal
    ttyn = os.ttyname(0)
OSError: [Errno 5] Input/output error
Ubiquity 18.04.14.14 (oem-config)
Traceback (most recent call last):
File "/usr/sbin/oem-config", line 655, in <module>
    main(oem_config)
File "/usr/sbin/oem-config", line 639, in main
    install(args[0], query=options.query)
File "/usr/sbin/oem-config", line 272, in install
    open_terminal()
File "/usr/sbin/oem-config", line 107, in open_terminal
    ttyn = os.ttyname(0)
OSError: [Errno 5] Input/output error

I don’t know if it can help

Hi tvai,

Are you using Etcher tool or flash command to flash image on sdcard?
Could you try below two thing?

  1. Flash image again with full flash command (without -r option)
  2. Connect HDMI monitor, check init setup process is show up.