[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! [b][i]This packages is at fault for overwriting nVidia's version:[/i][/b] [b][i]xserver-xorg-core[/i][/b] 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 /usr/lib/xorg/modules/extensions/libglx.so ...I'm not sure what the dpkg setup would be to keep nVidia's file and not overwrite it. [i]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).[/i] [b]--------------------------------------------------------------------------------------[/b] 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): [url]https://developer.nvidia.com/linux-tegra[/url] 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: [code]ssh -t ubuntu@tk1 'sudo ls /nvidia_drivers.tbz2'[/code] This should list files within the tar archive from host as executed on tk1: [code]ssh -t ubuntu@tk1 'sudo bunzip2 < /nvidia_drivers.tbz2 | tar --list'[/code] This should validate existing nVidia files from host as executed on tk1: [code]ssh -t ubuntu@tk1 'sudo sha1sum -c /etc/nv_tegra_release'[/code] 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"): [code]#!/bin/bash ssh -t ubuntu@tk1 'sudo sha1sum -c /etc/nv_tegra_release'[/code] 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): [code]ssh -t ubuntu@tk1 'cd / ; bunzip2 < /nvidia_drivers.tbz2 | sudo tar xv --overwrite usr/lib/xorg/modules/extensions/libglx.so'[/code] 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: [code]#!/bin/bash ssh -t ubuntu@tk1 'cd / ; bunzip2 < /nvidia_drivers.tbz2 | sudo tar xv --overwrite usr/lib/xorg/modules/extensions/libglx.so'[/code] 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: [code]bunzip2 < nvidia_drivers.tbz2 | tar --list[/code]
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:
xserver-xorg-core

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
/usr/lib/xorg/modules/extensions/libglx.so
...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):
https://developer.nvidia.com/linux-tegra

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"):
#!/bin/bash

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:
#!/bin/bash

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

#1
Posted 09/13/2014 06:45 PM   
[code]sudo apt-mark hold xserver-xorg-core[/code] _should_ do the job, I have NOT tried that yet, though.
sudo apt-mark hold xserver-xorg-core

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

#2
Posted 09/13/2014 07:20 PM   
It _did_ the job on my board. Thanks.
It _did_ the job on my board. Thanks.

#3
Posted 09/13/2014 08:05 PM   
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....
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....

#4
Posted 09/14/2014 10:01 AM   
Worked for me. Nice solution. Might be worth pinning this topic and adding it to the wiki somewhere. Thanks
Worked for me. Nice solution. Might be worth pinning this topic and adding it to the wiki somewhere.
Thanks

#5
Posted 09/14/2014 03:58 PM   
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.
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.

#6
Posted 09/15/2014 01:06 PM   
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.
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.

Official Jetson TK1 homepage:
https://developer.nvidia.com/embedded-computing
Official Jetson TK1 Wiki: https://developer.nvidia.com/jetson-wiki
Official Jetson TK1 Blog: http://bit.ly/1kt2wfx

#7
Posted 09/16/2014 01:33 AM   
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.
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.

#8
Posted 09/16/2014 03:15 PM   
I was told to never do apt-get upgrade but apt-get dist-upgrade instead. Would this have made a difference?
I was told to never do apt-get upgrade but apt-get dist-upgrade instead. Would this have made a difference?

#9
Posted 09/16/2014 07:27 PM   
[quote="beowulfs"]I was told to never do apt-get upgrade but apt-get dist-upgrade instead. Would this have made a difference? [/quote] 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.
beowulfs said: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.

#10
Posted 09/16/2014 07:52 PM   
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?
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?

#11
Posted 09/19/2014 11:24 PM   
[quote="beowulfs"]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?[/quote] Probably not. The dpkg understands permissions and is run with root authority...perms which it doesn't like it will change.
beowulfs said: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.

#12
Posted 09/19/2014 11:32 PM   
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?
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?

#13
Posted 09/24/2014 04:12 AM   
[quote="dogfishing"]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?[/quote] 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.
dogfishing said: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.

#14
Posted 09/24/2014 05:08 AM   
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.
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.

#15
Posted 09/27/2014 09:19 PM   
Scroll To Top

Add Reply