I’m using etcher, and via HDMI it’s working fine, but I want to use headless setup.
If I create an image with jetson-disk-image-creator.sh it’s working fine.
Please try again and remove your HDMI cable.
And check /dev/ttyACMx on your host ubuntu machine.
It’s already what I did so many times.
The screenshots I sent was connecting the HDMI cable after oem-config detects it’s headless setup, just to see the output when I get an error.
When it fails, I have only USB cable to my PC connected and power cable.
I just tried again:
- flash nv-jetson-nano-sd-card-image-r32.4.2.zip to a SD card with etcher
- connect USB cable to my host (running up to date ubuntu 18.04)
- connect power cable to J25 (with J48 ON)
- sudo picocom -b 115200 /dev/ttyACM0
I get the welcome screen, when I press OK with Enter key of a French keyboard, I get disconnected, and then when I run again the picocom command, I get the login screen with "localhost.localdomain login: "
Last friday I did theses steps 5 times, and same result.
Let me try with r32.3.1.
I am just wondering… does this issue still happen to sdcard image or even sdkmanager would hit this?
In your previous case, you said older sdcard image should not hit such issue but only latest rel-32.4.2 image will. Is this comment still true?
I’m trying it right now.
Yesterday I tried to create an image with the following steps, and the oem-config of the generated image was working fine, pressing OK on the welcome screen did not eject me and I could finish all the oem-config process.
tar xvpf /sdkm_downloads/Jetson-210_Linux_R32.4.2_aarch64.tbz2 cd Linux_for_Tegra/rootfs sudo tar xvpf /sdkm_downloads/Tegra_Linux_Sample-Root-Filesystem_R32.4.2_aarch64.tbz2 cd .. sudo ./apply_binaries.sh sudo tools/jetson-disk-image-creator.sh -o sd-blob-b01.img -b jetson-nano -r 300
I confirm you that flashing r32.3.1 image is working.
Just want to make sure about this again. Sorry in advance If you mentioned somewhere before.
- Have you tried other Nano devkit (if you have it)
- Have you tried other sdcard?
- Have you tried other host machine?
- Yes, I tried another nano devkit
- Yes, I tried another sdcard
- I would say yes, but right now I can’t test on another computer
This seems very strange because if I flash the r32.3.1 on the same SD, run it on the same nano and connect from the same PC, and it’s working fine.
I’ve seen many posts about people complaining about the r32.4.2 image not working in headless setup, maybe there is something that you don’t reproduce on your lab, but that happens on many computers over the world.
I don’t think I have a strange config, it’s a PC running ubuntu 18.04 in english (french keyboard, english locale), and I just hit “Enter” key on my keyboard, nothing more.
Ok, we will firstly check your oem-config.log.
I didn’t pay any attention but if you look at the log, it’s saying something about length of license… maybe it’s a clue, the license is maybe longer than the r32.3.1 one, and that could explain why it’s working on desktop, but not in headless setup.
One test could be to flash the SD card, mount it to reduce the size of the license, and test it in a nano devkit.
That could explain also why creating my own image with jetson-disk-image-creator.sh is working, I guess the license file is different from the official image.
I confirm you what I said before:
with exactly the same nano devkit, same PC, same SD card, I modified the license inside the SD card after flashing it with etcher, from my PC:
sudo mkdir /mnt/nano_sd_p1 sudo mount /dev/sdc1 /mnt/nano_sd_p1 sudo gzip -d "/mnt/nano_sd_p1/usr/share/doc/nvidia-tegra/NVIDIA End User License Agreements.txt.gz" sudo vim "/mnt/nano_sd_p1/usr/share/doc/nvidia-tegra/NVIDIA End User License Agreements.txt" # I kept the first 50 lines more or less sudo gzip "/mnt/nano_sd_p1/usr/share/doc/nvidia-tegra/NVIDIA End User License Agreements.txt" sudo umount /mnt/nano_sd_p1
is working fine
May I know your md5 checksum of sdcard image? I just consulted with internal team and they said this issue was already resolved and new sdcard image is on the download center. (and yes, it is really due to the large license content)
Please check if your have below md5sum for sd image.
Indeed, my file is “nv-jetson-nano-sd-card-image-r32.4.2.zip” with md5 “8cf36d838fe199ec7bef5f618b7c0aef” I downloaded it on 2020-04-30.
I downloaded the last one “nv-jetson-nano-sd-card-image-r32.4.2b.zip” with md5 “ebdf7b0ffdb3539606c654105466f956”, and indeed the problem is fixed.
Sorry for all this long post, I didn’t know about a new version with same version number. I should have downloaded it first.
I understand now why it may have worked once, I guess it was from my office computer, and not home computer.
We can mark this post as resolved.
I have another problem I did not have before because I always set up an IP address until now, but for this time I decided to not connect any Ethernet cable, and select:
- Primary network interface:
- Network configuration method:
Do not configure the network at this time
- Hostname: jetson-nano
Then during the following step, the connection is lost, and I have an error in the oem-config.log
System Configuration ┌───────────────────────────┤ Installing system ├───────────────────────────┐ │ Finding the distribution to copy... │ │ │ │ │ │ │ │ 0% │ │ │ └───────────────────────────────────────────────────────────────────────────┘ FATAL: term closed term_exitfunc: reset failed for dev UNKNOWN: Input/output error
I reconnect to the Jetson Nano, the username is OK, hostname too, I don’t know if the oem-config process has finished correctly or not.
myuser@jetson-nano:~$ cat /var/log/oem-config.log Ubiquity 18.04.14.14 (oem-config) debconf_ui selected; starting debconf frontend Ubiquity 18.04.14.14 (oem-config) Your console font configuration will be updated the next time your system boots. If you want to update it now, run 'setupcon' from a virtual console. Warning: The kernel is still using the old partition table. The new table will be used at the next reboot or after you run partprobe(8) or kpartx(8) The operation has completed successfully. Setting name! partNum is 0 Warning: The kernel is still using the old partition table. The new table will be used at the next reboot or after you run partprobe(8) or kpartx(8) The operation has completed successfully. resize2fs 1.44.1 (24-Mar-2018) Filesystem at /dev/mmcblk0p1 is mounted on /; on-line resizing required old_desc_blocks = 2, new_desc_blocks = 8 The filesystem on /dev/mmcblk0p1 is now 15588347 (4k) blocks long. sh: 1: kill-all-dhcp: not found sh: 1: kill-all-dhcp: not found grep: /target/etc/apt/sources.list: No such file or directory open /dev/tty: No such device or address debconf: whiptail output the above errors, giving up!
it’s not critical, I can set up ethernet during oem-config to avoid this problem.