[L4T R19.x] Notice On apt-get upgrade: libglx.so Corruption

I saw an xorg update, so I thought I’d check out if this is what has been troubling people. It is!

This packages is at fault for overwriting nVidia’s version:

Before upgrading those two packages (comes with xserver-common), deselect xserver-xorg-core.

For nVidia:
L4T contains file Linux_for_Tegra/nv_tegra/config.tbz2. This is for apply_binaries.sh, and this is where L4T should be modified to safeguard
…I’m not sure what the dpkg setup would be to keep nVidia’s file and not overwrite it.

EDIT: For those who lost graphics/X11 login, remember that serial port and ethernet still work. You should be able to use scp to copy files from another machine to Jetson even when graphics fail. You can also copy files to a USB thumb drive or SD card (typically auto mounts under /media).

NOTE: The start page for downloading various L4T versions is here…if you need the replacement of libglx.so and do not have it this might be where you will find it (original R19.2 is not available and R19.3 can’t be mixed with R19.2):

EDIT: People should keep their Jetson systems up to date, and it may be that a simplification of remotely restoring the libglx.so file is in order. I sense a fear in “apt-get upgrade”. So here is a way to remotely reinstall nVidia files with less hassle.

NOTE: ssh option “-t” allows for answering questions from the remote system, e.g., password when using sudo; also, this assumes your Jetson has address “tk1” (adjust to your taste, replace “tk1” with whatever you use).

Preparation BEFORE any failure:
Copy the master tar of all nVidia files to “/” of tk1. This exists in your host’s nVidia L4T release in subdirectory “nv_tegra” as nvidia_drivers.tbz2. Use scp or any method you might use to place this as root ownership in “/” (e.g., use sudo scp from tk1 to pull from host, or copy as ubuntu ownership and later use “sudo chown root.root nvidia_drivers.tbz2”). E.G., initially copy this to ubuntu@tk1’s home directory and then use sudo to move and change ownership to “/nvidia_drivers.tbz2”. This file contains all of nVidia’s files which may need re-installation if some part of Ubuntu were to overwrite the files. libglx.so is one of those files. Unpacking this file as root (or sudo) is the same as running “apply_binaries.sh” on the sample rootfs.

Validate this file is in place and that you have ssh access. From remote host this should list the file (asking twice for password…once for ssh, once for sudo) on tk1:

ssh -t ubuntu@tk1 'sudo ls /nvidia_drivers.tbz2'

This should list files within the tar archive from host as executed on tk1:

ssh -t ubuntu@tk1 'sudo bunzip2 < /nvidia_drivers.tbz2 | tar --list'

This should validate existing nVidia files from host as executed on tk1:

ssh -t ubuntu@tk1 'sudo sha1sum -c /etc/nv_tegra_release'

NOTE: The “-t” option of ssh can’t be used directly with scp, but you can use “ssh -t ‘sudo scp …’” and be creative.

On host, this script (with passwords) will check nVidia files (mine is in /usr/local/bin and is named “remote_nv_check.sh”):


ssh -t ubuntu@tk1 'sudo sha1sum -c /etc/nv_tegra_release'

Next, a remote extract example, but beware permissions must be preserved and without root or root authority (sudo) this won’t happen (also note that naming exact file in this case names a relative path and so you must be in “/” when running this…it is the tar archive listing that determines the relative path):

ssh -t ubuntu@tk1 'cd / ; bunzip2 < /nvidia_drivers.tbz2 | sudo tar xv --overwrite usr/lib/xorg/modules/extensions/libglx.so'

Simply run the above command with the exact path of any file shown to not pass the remote_nv_check.sh command. One could make a script specific to libglx.so (and add others to the list if desired), e.g., create remote_nv_libglx_fix.sh:


ssh -t ubuntu@tk1 'cd / ; bunzip2 < /nvidia_drivers.tbz2 | sudo tar xv --overwrite usr/lib/xorg/modules/extensions/libglx.so'

Replacing any file in the same way is easy once you know this commad. To get the list of all files available in the nvidia_drivers.tbz2:

bunzip2 < nvidia_drivers.tbz2 | tar --list
sudo apt-mark hold xserver-xorg-core

should do the job, I have NOT tried that yet, though.

It did the job on my board. Thanks.

Thank you, was having this problem too, drove me crazy

Yes, doing a “sudo apt-get upgrade” overrides “/usr/lib/xorg/modules/extensions/libglx.so”

running “sha1sum -c /etc/nv_tegra_release” will confirm if your binary video driver is installed correctly

I enabled compiz with plugins but on next reboot X session does not want to login…

Worked for me. Nice solution. Might be worth pinning this topic and adding it to the wiki somewhere.

If you do have corrupted libglx.so, look in the Tegra124_Linux_R19.30.0_armhf.tbz2 archive you used when flashing L4T. It will be located at Linux_for_tegra/nv_tegra/nvidia_drivers/usr/lib/xorg/modules/extensions/libglx.so. Copy that over to the corresponding location on your Jetson.

Nice work linuxdev & enthusi on figuring out the problem & a solution! I’ll mark this as a sticky thread, and try to get it fixed for the next L4T release so that it hopefully won’t require workarounds for much longer.

This also happened to me. I just wanted to add, ctrl-alt-f1 to get a command line at the black screen after the nvidia logo. Saw that tip on another thread.

I was told to never do apt-get upgrade but apt-get dist-upgrade instead. Would this have made a difference?

No. I’m not too savvy with apt-get, but basically I think “dist-upgrade” is willing to install missing packages, whereas “upgrade” does not. xserver-xorg-core is already installed, but it doesn’t know that libglx.so is from nVidia instead of itself.

Modify the script to make file read only.

For incremental, modify script to check for file, make it writable, update it, make it read only.

Would that stop xorg?

Probably not. The dpkg understands permissions and is run with root authority…perms which it doesn’t like it will change.

after replacing this libglx.so file and rebooting I get login screen on unity but then after putting password in, the nvida driver image shows up and i am again prompted with the login screen. Any ideas why this is happening?

Sounds as if X11 is crashing for other reasons. Log in on serial console if needed, run:
sha1sum -c /etc/nv_tegra_release
…see if anything else was overwritten.

Check /var/log/Xorg.log after a failure, or even tail -f the log and watch as it fails. See what it tells you.

I’ve copied libglx.so to /usr/lib/xorg/modules/extensions/libglx.so but sha1sum still says it failed (it’s the only one that fails).

I can log into tty1.

When I reboot it does eventually get me to the GUI log-in screen, but when I log in I can only see the desktop background and move my mouse around, but nothing else seems to respond.

:( all I wanted to do was upgrade my shinny new tk1 …

Edit: I re-ran the installer script and that worked.

copying libglx.so did not work for me.

notwithstanding warning in README I re-ran installer script and this did work with 1 warning:

mv: cannot stat ‘/etc/init/lightdm.override’: No such file or directory


Did you take the libglx.so file from the driver package available here?
I moved the file to the Jetson using scp, so after moving it to to the proper location “/usr/lib/…”, I also made sure to change the owner and group of the file to root, with the chown command:

sudo chown root:root libglx.so

Then, I got all OK when issuing:

sha1sum -c /etc/nv_tegra_release

Thanks to all who shared the solution to this problem!

Thanks both of linuxdev and enthusi this solved the gui problem for me

This thread saved me a lot of time. Overwriting the corrupt libglx.so with the version from the Tegra.bz2 fixed my problem. Thanks everyone!

I have followed all of the help and steps that I could find on this forum. So far in the 50 or so attempts to start the Jetson, since the flash, the board actually initializes the boot loader(scrolling text on the screen) about 7 times, and only 3 of those times have made it to the GUI. Every other time the board turns on but nothing ever happens. It won’t even turn on the USB HUB. Which always happens just a moment before the text shows up on the screen. I don’t understand why NVIDIA would release a board like this to the public that has so many issues. Has anyone else had boot issues like this? Does anyone have any suggestions?