System update breaks terminal

Basically title.

Followed official getting started guide from nVidia website and when i’ve done with system update i got msg

There was an error creating the child process for this terminal. Failed to open PTY: Permission denied.

Happens on nano and NX! Someone know how can i solve this?

Does this permission error occur for all of these, or just for part of them:

  • ssh login.
  • Terminals created in the GUI.
  • Terminals from non-GUI mode, e.g., if in GUI, then CTRL-ALT-F3 goes to a non-GUI terminal, and if in the non-GUI terminal, either ALT-F1 or ALT-F2 goes back to the GUI (depends on whether the GUI is “$DISPLAY” of “:0” or “:1”).

Is this an SD card model, or is it an eMMC model? Is this a dev kit, or is this a third party carrier board?

will check for ssh login. All terminals created in the GUI yields permission error, CTRL+ALT+3 just turns off screen. Its SD card model and yes its dev kit

edit: permission error also occurs on ssh login

If you plug your SD card into a host PC, but run “dmesg --follow” to watch logs prior to plugging it in, then it will tell you which device the SD card is on your host PC. For example, it might show up as “/dev/sdb” or “/dev/mmcblk0”. I’ll pretend it is “/dev/sdb”. On the host PC, what do you see for:
lsblk -f /dev/sdb

Also, do you have either another spare SD card, or room on your host PC disk drive to save a clone of that failing SD card content? For the case of cloning onto the host, if the SD card is 64GB, then you’d need 64GB of spare space on the host to perform a clone.

If i understood your question, this is what came from lsblk -f /dev/sdb

zm@nano001:~$ lsblk -f /dev/mmcblk0
NAME         FSTYPE LABEL UUID                                 MOUNTPOINT
├─mmcblk0p1  ext4         ff2880cc-1a99-40bd-88c1-5cdc86fe9eed /

If you mount the SD card’s first partition ("/dev/mmcblk0p1" on the host PC (it might auto mount…use “df -H /dev/mmcblk0p1” on the host PC to see if it is already mounted), then we could examine a few things. I’ll assume mmcblk0p1 is mounted on “/mnt” of the host PC, but it could be somewhere else, e.g., “/var/run/usr/1000/”. Wherever it is actually mounted, then “cd” to that location first. Then look for the following…

ls -ltr /var/log/Xorg*
# Now copy the last one listed, which is the most recently modified Xorg log...
# probably it is "`/var/log/Xorg.0.log`", but it might e "`/var/log/Xorg.1.log`".
# Copy to your host PC, rename it with a "`.txt`" file name extension, and post
# in the forums.

# Next, examine the permissions of "`sudo`", and remember you must be at the mount point (note
# that the extra leading "./" is important, this is a relative path, not a "`/`" full path):
ls -ld ./usr/bin/sudo
ls -ld ./sbin/*getty*

In addition to that log, what is the output from the “ls -ld” of those files?

Xorg.1.txt (51.3 KB)

and outputs are
ls -ld ./usr/bin/sudo:
-rwsr-xr-x 1 root root 136616 jan. 19 15:36 ./usr/bin/sudo

ls -ld ./sbin/*getty*:

-rwxr-xr-x 1 root root 52296 sep.  16 20:43 ./sbin/agetty
lrwxrwxrwx 1 root root     6 sep.  16 20:43 ./sbin/getty -> agetty

The getty programs and sudo look correct.

Looking at the log, I see something wrong, but don’t know which specific package failure installed the Nouveau driver in place of the NVIDIA driver. To be clear, there are Nouveau packages which are valid on the system, but the one which works as the video driver itself cannot be Nouveau. These log lines are of interest:

[    32.826] (==) Matched nouveau as autoconfigured driver 1
[    32.826] (II) LoadModule: "nouveau"
[    32.826] (II) Loading /usr/lib/xorg/modules/drivers/
[    32.827] (II) Module nouveau: vendor="X.Org Foundation"
[    32.827] 	compiled for 1.20.3, module version = 1.0.16
[    32.827] 	Module class: X.Org Video Driver
[    32.827] 	ABI class: X.Org Video Driver, version 24.0
[    32.827] (II) NOUVEAU driver Date:   Mon Jan 28 23:25:58 2019 -0500
[    32.827] (II) NOUVEAU driver for NVIDIA chipset families :
[    32.827] 	RIVA TNT            (NV04)
[    32.827] 	RIVA TNT2           (NV05)
[    32.828] 	GeForce 256         (NV10)
[    32.828] 	GeForce 2           (NV11, NV15)
[    32.828] 	GeForce 4MX         (NV17, NV18)
[    32.828] 	GeForce 3           (NV20)
[    32.828] 	GeForce 4Ti         (NV25, NV28)
[    32.828] 	GeForce FX          (NV3x)
[    32.828] 	GeForce 6           (NV4x)
[    32.828] 	GeForce 7           (G7x)
[    32.828] 	GeForce 8           (G8x)
[    32.828] 	GeForce 9           (G9x)
[    32.828] 	GeForce GTX 2xx/3xx (GT2xx)
[    32.828] 	GeForce GTX 4xx/5xx (GFxxx)
[    32.828] 	GeForce GTX 6xx/7xx (GKxxx)
[    32.828] 	GeForce GTX 9xx     (GMxxx)
[    32.828] 	GeForce GTX 10xx    (GPxxx)

Any time the X server tries to load the direct rendering code, but instead finds a Nouveau driver, you will have a crash of the X server. The above could be valid on a desktop PC if and only if the NVIDIA driver were not used, but a Jetson will never have Nouveau server rendering without some explicit installation of this (which would result in crashing in most cases). It is my belief that the update somehow picked up on a Nouveau GPU package as a replacement to the NVIDIA GPU package.

The above would not directly break with a “permissions” issue, but could perhaps do so indirectly. I won’t be able to answer which packages are involved, but someone who does answer will want to know which L4T version is installed. If your SD card is mounted on your host PC, and you do the same cd to the location of the mount, then this would tell you the exact version:
head -n 1 ./etc/nv_tegra_release

The following debug output would also possibly help in finding the package which is overwritten (also run on the host PC from the mount point of the SD card partition):

 ls -ld `find ./usr/lib/aarch64-linux-gnu/ -name '*GL*'` | egrep '(GL|nvidia|tegra)'

(the leading “.” in the find directory must be present, and the command must be run from the mount point of the SD card on the host PC)

From this someone with that particular release would be able to find out which NVIDIA package was replaced with a Nouveau package (although it might not be easy).

Sorry for late reply, life happened.

I was trying to install OpenDataCam on my device, so every time i’ve installed it on docker-compose that happened

Thanks for your help, tho, will try to find way to install it without docker or something

Just make sure your docker uses NVIDIA packages and not Nouveau (at least not the driver part of Nouveau…some Nouveau non-driver packages might be valid).

Will try to keep that in mind, but I have no experience with docker really.

Found solution though, sudo chmod 666 /dev/pts/ptmx fixed terminal

1 Like