System configuration wizard doesn't come out

Robotics & Edge Computing Jetson & Embedded Systems Jetson TX2
1

Hi,

I am flashing Jetpack 3.3.1/3.3.2 on Jetson TX2 using Nvidia SDK Manager.

After the target flashed successfully, a sdk window poping out says Complete the Ubuntu System COnfiguration Wizard on your Jetson TX2, the strange thing is the system configuration wizard doesn’t come out, my Jetson enters ubuntu desktop immedately without any settings.

The flashed OS used default user name and passwd as nvidia&nvidia. I can ssh it use this usr&passwd.
It works correctly in most of the time without locale setting, except for

  1. usb driver doesn’t work, reboot tx2 makes it work,
  2. many “perl: warning: Setting locale failed” problems.

Is this normal?

I used

  • Jetson TX2
  • HDMI monitor
  • USB HUB
  • Mouse and keyboard
  • SDK manager 1.0.0.5517
  • Jetpack 3.3.1 & 3.3.2

There are lots of errors during flashing, but completed sucessfully.

15:28:55 ERROR : Flash Jetson TX2 : Board ID(3310) version(D00)
15:29:36 ERROR : Flash Jetson TX2 :
15:29:36 ERROR : Flash Jetson TX2 : 0: RAW: 4255744( 1039 blks) ==> 28:4255756
15:29:36 ERROR : Flash Jetson TX2 : 1: SKP: 24576( 6 blks) ==> 4255784:12
15:29:36 ERROR : Flash Jetson TX2 : 3: SKP: 61440( 15 blks) ==> 4259904:12
15:29:36 ERROR : Flash Jetson TX2 : 5: SKP: 33550336( 8191 blks) ==> 4264024:12
....
15:29:53 ERROR : Flash Jetson TX2 : 2861: SKP: 2012794880( 491405 blks) ==> 3536586296:12
15:29:53 ERROR : Flash Jetson TX2 : -- Total: ---------------------------------------------------

Screenshot2020-01-01-035302.png
Screenshot2020-01-01-035302.png1401×898 232 KB

SDKM_logs_JetPack_3.3.2_Linux_for_Jetson_TX2_2020-01-01_15-28-21.zip (1.08 MB)

2

For JetPack 3.x and earlier the accounts were created by default and there was no need to add them.

The ERROR messages related to RAW/SKP is an error on the host PC side in preparation for flash. In this case it implies that even if the flash is correct, that the image flashed has problems.

Flash will build an image prior to starting the flash, and that image will be an exact bit-for-bit match of what gets flashed. The implication is that if the image is about 30GB in size, then this much space will also be taken on the host PC. Then a sparse image is created, which in turn is about two or three GB. Other smaller images are involved as well. Perhaps your PC ran out of disk space and flashed a truncated image. What do you see on the host from:

df -H -T -t ext4

Note that I specifically limited the query to ext4 since non-Linux filesystem types cannot be used for image creation (the rootfs which is used to create the image must preserve Linux permissions and non-Linux filesystem types do not understand Linux permissions).

3

Thank you for your detailed explanation @linuxdev. Happy New Year~

My /home folder only has 28GB available space, this might be the reason.
run df -H -T -t ext4 on my laptop host

Filesystem     Type  Size  Used Avail Use% Mounted on
/dev/sda3      ext4  197G   48G  140G  26% /
/dev/sda5      ext4  2.0G  126M  1.7G   7% /boot
/dev/sda6      ext4  252G  211G   28G  89% /home

I released more space, 130GB now, but the result is same.

Filesystem     Type  Size  Used Avail Use% Mounted on
/dev/sda3      ext4  197G   48G  140G  26% /
/dev/sda5      ext4  2.0G  126M  1.7G   7% /boot
/dev/sda6      ext4  252G  109G  130G  46% /home

Any ideas?

As for “perl: warning: Setting locale failed” problem, run locale on TX2 results the following

locale: Cannot set LC_ALL to default locale: No such file or directory
LANG=en_US.UTF-8
LANGUAGE=
LC_CTYPE="en_US.UTF-8"
LC_NUMERIC=zh_CN.UTF-8
LC_TIME=zh_CN.UTF-8
LC_COLLATE="en_US.UTF-8"
LC_MONETARY=zh_CN.UTF-8
LC_MESSAGES="en_US.UTF-8"
LC_PAPER=zh_CN.UTF-8
LC_NAME=zh_CN.UTF-8
LC_ADDRESS=zh_CN.UTF-8
LC_TELEPHONE=zh_CN.UTF-8
LC_MEASUREMENT=zh_CN.UTF-8
LC_IDENTIFICATION=zh_CN.UTF-8
LC_ALL=

I add the following code in ~/.bashrc file, it works.

export LANGUAGE=en_US.UTF-8
export LC_ALL=en_US.UTF-8
4

Yes, there is a strong chance the image was truncated. The flash software produces a “Linux_for_Tegra/” directory on the host PC, and within this the “Linux_for_Tegra/bootloader/system.img.raw” file. Can you see the exact byte size of this?

cd /where/ever/it/is/Linux_for_Tegra/bootloader
ls -l system.img.raw

That file must be evenly divisible by 1024 at least twice, but sometimes it is divisible by 1024 three times. This is the first temp file created in a series of copies and generation of content.

Even if that file is a correct size, there would also be a system.img on top of this, and a number of other images/files copied around. In the long run, if you have a way to increase space (e.g., 35GB total or more), then this would be the next thing to test.

Note that non-UTF8 locales can cause problems, or spaces in the path to the install software, but this won’t necessarily be a problem. The export you ran should be good enough for anything other than spaces in a file path. This would still be a problem if that locale cannot be found…it could be the en_US.UTF-8 content for that locale does not exist on your computer. FYI, it is safe to add multiple locale support so long as the system as a whole does not get set to the wrong locale. I have for example installed some other locales on my system to be able to see non-en_US punctuation and fonts, but this is purely en_US.UTF-8.

5

Hi @linuxdev,

The size of system.img.raw is 28GB

-rw-r--r-- 1 root root 30064771072 1月   2 12:00 system.img.raw

I have increased space as mentioned in my last post, but the result is the same.

Filesystem     Type  Size  Used Avail Use% Mounted on
/dev/sda3      ext4  197G   48G  140G  26% /
/dev/sda6      ext4  252G  137G  102G  58% /home
/dev/sda5      ext4  2.0G  126M  1.7G   7% /boot
6

The above says that the raw image is probably correct. After this raw image is created other content is created, but since you increased the home directory size, it is safe to conclude this is not the result of lack of space, nor of truncated images.

There is still a possibility that the software incorrectly handles spaces or non-en_US.UTF-8 characters in the path. In the location where the “Linux_for_Tegra/” directory is located, is the full path of the directory using any space characters or non-en_US.UTF-8 characters? If so, then it is worth testing via renaming that path to contain just those characters.

In the location where the “Linux_for_Tegra/” directory is found, you might then want to manually run the flash and log that. Assuming the “Linux_for_Tegra/rootfs/” is already correctly populated (and the earlier flash may not have done so, but it is very likely the content is correct), then you could put the Jetson in recovery mode and attach the micro-B USB, followed by this to flash and create a log:

sudo ./flash.sh jetson-tx2 mmcblk0p1 2>&1 | gawk '{gsub("[0-9][0-9]+[/][0-9[0-9]+ bytes sent..",".");print}' | tee log.txt

(if you don’t have “gawk”, then “sudo apt-get install gawk”)

If flash fails, then you can post the log.

If the Jetson itself still behaves oddly, then you can boot with serial console attached, and post the serial console log. If flash is valid, but boot is incorrect, then I would suspect the content of the “Linux_for_Tegra/rootfs/” directory being incorrect.

7

Hi @Linuxdev,

There are no spaces and other characters in the path. The absolute path of “Linux_for_Tegra/” is
/home/wang/nvidia/nvidia_sdk/JetPack_3.3.2_Linux_GA_P3310/Linux_for_Tegra

I mannually run the flash and log it, there are tons of similar things but doesn’t say they are error info.
This is output of flashing mannually

2896: RAW:        8192(      2 blks) ==>  3453110236:8204
2897: SKP:       57344(     14 blks) ==>  3453118440:12
2898: RAW:     3547136(    866 blks) ==>  3453118452:3547148
2899: SKP:    30007296(   7326 blks) ==>  3456665600:12
2900: RAW:     5853184(   1429 blks) ==>  3456665612:5853196
2901: SKP:    94679040(  23115 blks) ==>  3462518808:12
2902: RAW:    67108864(  16384 blks) ==>  3462518820:67108876
2903: SKP:    33554432(   8192 blks) ==>  3529627696:12
2904: RAW:     6832128(   1668 blks) ==>  3529627708:6832140
2905: SKP:  1905770496( 465276 blks) ==>  3536459848:12
-- Total: ---------------------------------------------------
2906 CHUNK 30064771072(7340032 blks) ==>  3536459860(863385 blks)

done.
system.img built successfully.

This is terminal output using SDK Manager, the difference is there are tags 'INFO` and ‘ERROR’ in it.

11:14:07 INFO : Flash Jetson TX2 : 2739: SKP: 8192( 2 blks) ==> 3454324864:12
11:14:07 ERROR : Flash Jetson TX2 : 2740: RAW: 106496( 26 blks) ==> 3454324876:106508
11:14:07 INFO : Flash Jetson TX2 : 2741: SKP: 20480( 5 blks) ==> 3454431384:12
11:14:07 ERROR : Flash Jetson TX2 : 2742: RAW: 65536( 16 blks) ==> 3454431396:65548
11:14:07 INFO : Flash Jetson TX2 : 2743: SKP: 8192( 2 blks) ==> 3454496944:12
11:14:07 ERROR : Flash Jetson TX2 : 2744: RAW: 61440( 15 blks) ==> 3454496956:61452
11:14:07 INFO : Flash Jetson TX2 : 2745: SKP: 12288( 3 blks) ==> 3454558408:12
11:14:07 ERROR : Flash Jetson TX2 : 2746: RAW: 82001920( 20020 blks) ==> 3454558420:82001932
11:14:08 ERROR : Flash Jetson TX2 : 2747: SKP: 1717362688( 419278 blks) ==> 3536560352:12
11:14:08 ERROR : Flash Jetson TX2 : -- Total: ---------------------------------------------------
11:14:08 INFO : Flash Jetson TX2 : 2748 CHUNK 30064771072(7340032 blks) ==> 3536560364(863410 blks)
11:14:08 INFO : Flash Jetson TX2 :
11:14:08 INFO : Flash Jetson TX2 : done.
11:14:08 INFO : Flash Jetson TX2 : system.img built successfully.

Even though both of them are built successfully in the end, what is these error info?
log.txt (423 KB)

8

The manual flash shows correct behavior, it is only the SDKM log which shows problems. Since SDKM is only a front end to the manual flash, the manual command line flash should be used for initial install (but extra packages cannot be installed like this…keep in mind that SDKM can have flash unchecked and be told to just install packages to a fully booted and running Jetson). My conclusion is that the actual flash from command line is 100% successful and valid (provided that the content being flashed is valid…flash itself does not know any difference between valid or invalid root partitions, it is all just binary data to the flasher).

If all you do is to flash manually on command line, does the Jetson boot correctly? If not, then on first boot after manually flashing, can you provide a serial console boot log? The goal is to see what goes on in boot when SDK Manager is not involved.