Command line access in Tx2 devloper kit instead of GUI

we have booted our Tx2 developer kit with default image but it has GUI interface and for our development we want to use command line access of device.

how we can enable this command line access of Tx2 EVK in our image.

Depending on release, this might not work, but try:

# First go multi-user:
sudo systemctl isolate
# Change default:
sudo systemctl set-default
# Now reboot and test.

(standard systemctl settings work in some releases, but not all)

what i saw in Tx2,we need to setup(user name/password) from GUI whenever we flash new image,that should be possible through command line console also,instead of running these systemctl command can we do changes in rootf,etc file to disable GUI(instead of command can we change in file)so that it will automatically disable GUI during device reboot,i dont want to run these commands separately.

Run the first boot setup through serial console and this should do what you want. For serial console see:

The commands which you have mentioned we can only use after login but after flashing new image we are not reaching there,we are getting below mesg in console after device bootup first time after flashing new image.

Model: NVIDIA P2771-0000-500
DRAM: 3.8 GiB
MC: Tegra SD/MMC: 0, Tegra SD/MMC: 1
*** Warning - bad CRC, using default environment

In: serial
Out: serial
Err: serial
Net: eth0: ethernet@2490000
Hit any key to stop autoboot: 0
MMC: no card present
switch to partitions #0, OK
mmc0(part 0) is current device
Scanning mmc 0:1…
Found /boot/extlinux/extlinux.conf
Retrieving file: /boot/extlinux/extlinux.conf
857 bytes read in 112 ms (6.8 KiB/s)
1: primary kernel
Retrieving file: /boot/initrd
5565615 bytes read in 192 ms (27.6 MiB/s)
Retrieving file: /boot/Image
34265096 bytes read in 855 ms (38.2 MiB/s)
append: console=ttyS0,115200 androidboot.presilicon=true firmware_class.path=/etc/firmware root=/dev/mmcblk0p1 rw rootwait rootfstype=ext4 console=ttyS0,115200n8

Flattened Device Tree blob at 80000000

Booting using the fdt blob at 0x80000000
reserving fdt memory region: addr=80000000 size=10000
Using Device Tree in place at 0000000080000000, end 000000008005de75

Starting kernel …

[ 0.000000] Booting Linux on physical CPU 0x100
[ 0.000000] Linux version 4.9.140 (d221626@PC-D221626) (gcc version 7.3.1 20180425 [linaro-7.3-2018.05 revision d29120a424ecfbc167ef90065c0eeb7f91977701] (Lina0
[ 0.000000] Boot CPU: AArch64 Processor [411fd073]
[ 0.000000] OF: fdt:memory scan node memory@80000000, reg size 16416,
[ 0.000000] OF: fdt: - 80000000 , 70000000
[ 0.000000] OF: fdt: - f0200000 , 85600000
[ 0.000000] OF: fdt: - 175e00000 , 200000
[ 0.000000] OF: fdt: - 176600000 , 200000
[ 0.000000] OF: fdt: - 177000000 , 200000
[ 0.000000] earlycon: uart8250 at MMIO32 0x0000000003100000 (options ‘’)
[ 0.000000] bootconsole [uart8250] enabled
[ 0.000000] Found tegra_fbmem2: 00800000@9607d000
[ 0.000000] Found lut_mem2: 00002008@9607a000
[ 3.627776] cgroup: cgroup2: unknown option “nsdelegate”
[ 4.507083] using random self ethernet address
[ 4.512183] using random host ethernet address
[ 4.827041] using random self ethernet address
[ 4.831580] using random host ethernet address
[ 6.624112] Please complete system configuration setup on desktop to proceed…
[ 153.992929] CPU1: shutdown
[ 154.077956] CPU2: shutdown

how we can remove this message “Please complete system configuration setup on desktop to proceed…” ,for this we need to use Desktop each time to configure the system after flashing new image that we dont want to do.
how can we remove this message,we want to reach at login prompt directly without doing Desktop configuration.

If serial console does not allow setup, then reboot the system and the next boot should make it available to set up. If that fails, then you’ve found a bug (assuming this is not an older release with a default login name/pass). Can we verify what L4T release is used? Typically you could use either “head -n 1 /etc/nv_tegra_release” or “dpkg -l | grep 'nvidia-l4t-core'”.

we are using SDK 32.4.3,serial console is waiting to setup user/password from desktop,first we need to login using desktop only then we can run any command.
Any other way to bypass this,in earlier version of SDK 28.2 no issue was there

If serial console is connected, but not a monitor and keyboard, then first boot setup should be possible over serial console. If that is not the case, then you found a bug (at least in most of the recent releases, and R32.4.3 qualifies as recent). This script allows setup prior to flash:

The reason this change occurred is due to legal reasons in the state of California.

I applied this script prior to flash and it is working fine for first time only,but when we are applying it second time with same user name and password we are not getting login console,can we apply any check in the user script that if it is already applied it should not apply again.
any help will be appreciated.

If you use that script it alters the image on the host PC side. From then on all flashes will have already completed first boot setup, and the account name/pass will be the same on all flashes.

Are you trying to run the script again to get a different timezone and/or user name/pass? If so, then it doesn’t work to just run the script again. The script is running a command to add a user name/pass, and this command will fail if the user is already in existence.

If for some reason you are using SDK Manager, and SDKM downloads a new copy of the “Linux_for_Tegra/rootfs/” content, then your original changes would be overwritten.

Can you give some details about what kind of use case you are working with? The work flow you need would make it easier to answer.

Incidentally, that script can be edited.

Actually we have added this script in apply and we are in devlopment phase so each time we have to do some changes in driver and all and compile it and running apply binary again and again so these script is also using again and again thats why i was asking that can we change this script if it is already applied it will skip when we again apply it.

The script assumes the account does not exist, and tries to create it. If you try to create an account which is always there, then of course it will fail.

You could for example check the output of “sudo passwd -S” (you are probably already running the script as root, so maybe you don’t need “sudo”) and run the actual create only if the expected user is not there. An example for a non-existent user “abcde”:

# sudo passwd -S abcde
passwd: Unknown user name 'abcde'.

If the “-S” output is anything else, then you could just run a change of password based on the expected user name to avoid every flash having the password…but you’d have log the password, e.g., by having the main script pass the future password to the QEMU part. Only needed if you don’t want every password to be a default (which wouldn’t be legal to ship to California with a default).

Under “man passwd” you can also see different return values for different kinds of failures, and you could check return values.

The “useradd” and “usermod” commands ("man useradd" or “man usermod”) also have man pages listing things you could use for automation in a script.

In all cases I’ll advise knowing about the “numeric” user and group IDs, and that you want to guarantee your first admin user is UID/GID 1000. If this is the first account created, then this will happen by default, but if something else got added, then it will increment and might not be what you expect. “Preserving” numeric UID/GID in any kind of backup/restore is very important, and to some extent, a script to create a new user is a category of restore.