[L4T R19.x] Notice On apt-get upgrade: libglx.so Corruption
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 ~:"
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

~:"

#16
Posted 09/29/2014 08:02 AM   
[quote="peepocom"]copying libglx.so did not work for me.[/quote] Did you take the libglx.so file from the driver package available [url=https://developer.nvidia.com/linux-tegra-rel-19]here[/url]? 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: [code]sudo chown root:root libglx.so[/code] Then, I got all OK when issuing: [code]sha1sum -c /etc/nv_tegra_release[/code] Thanks to all who shared the solution to this problem!
peepocom said:copying libglx.so did not work for me.


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!

"All those moments will be lost in time like tears in the rain."

#17
Posted 09/30/2014 07:19 PM   
Thanks both of linuxdev and enthusi this solved the gui problem for me
Thanks both of linuxdev and enthusi this solved the gui problem for me

#18
Posted 10/01/2014 06:20 PM   
This thread saved me a lot of time. Overwriting the corrupt libglx.so with the version from the Tegra<etc>.bz2 fixed my problem. Thanks everyone!
This thread saved me a lot of time. Overwriting the corrupt libglx.so with the version from the Tegra<etc>.bz2 fixed my problem. Thanks everyone!

#19
Posted 10/05/2014 03:29 PM   
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?
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?

#20
Posted 10/07/2014 10:45 PM   
[quote="Trillian"]I have followed all of the help and steps that I could find on this forum.[/quote] Please attach the serial logs of a failing case. That may reveal what is going wrong or at least where it gets stuck.
Trillian said:I have followed all of the help and steps that I could find on this forum.


Please attach the serial logs of a failing case. That may reveal what is going wrong or at least where it gets stuck.

#21
Posted 10/08/2014 07:07 AM   
I thought my board was dead, with no GUI at all. I tried to do an SSH log in and it worked! So, my board was not completely dead after all! Then I read this thread and it all made sense, the X server had been outdated. While your board is on and enough time had passed for it to boot up, try to log in through ssh, using a second computer of course. If that works, log out and move the libglx.so file to the proper location using scp. Check your changes with sha1sum and then restart your Jetson. The next thing you do is lock it up! [code]sudo apt-mark hold xserver-xorg-core[/code] I Hope it helps.
I thought my board was dead, with no GUI at all. I tried to do an SSH log in and it worked! So, my board was not completely dead after all! Then I read this thread and it all made sense, the X server had been outdated.

While your board is on and enough time had passed for it to boot up, try to log in through ssh, using a second computer of course. If that works, log out and move the libglx.so file to the proper location using scp. Check your changes with sha1sum and then restart your Jetson.

The next thing you do is lock it up!

sudo apt-mark hold xserver-xorg-core


I Hope it helps.

"All those moments will be lost in time like tears in the rain."

#22
Posted 10/08/2014 03:50 PM   
[quote="Trillian"]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?[/quote] Others have mentioned...[i]we need logs[/i]. The log from serial console for boot up till failure would be a good idea. When a flash is involved we need to know the exact flash command used, and some things about host environment, e.g., was ALL host involvement done as root (such as unpacking tar files)? Was the host running on a native linux file system, and not a virtual system on top of another file system? What was the exact flash command used (and especially I hope ODMDATA was not anything but default)? How did the system behave prior to flash? The libglx.so issue would occur only if doing an apt-get upgrade on a working system, and then only if a particular package is upgraded. It's easy to check if you run "sha1sum -c /etc/nv_tegra_release" after each apt-get upgrade.
Trillian said: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?


Others have mentioned...we need logs. The log from serial console for boot up till failure would be a good idea.

When a flash is involved we need to know the exact flash command used, and some things about host environment, e.g., was ALL host involvement done as root (such as unpacking tar files)? Was the host running on a native linux file system, and not a virtual system on top of another file system? What was the exact flash command used (and especially I hope ODMDATA was not anything but default)? How did the system behave prior to flash?

The libglx.so issue would occur only if doing an apt-get upgrade on a working system, and then only if a particular package is upgraded. It's easy to check if you run "sha1sum -c /etc/nv_tegra_release" after each apt-get upgrade.

#23
Posted 10/08/2014 04:19 PM   
[quote="Nexus8"] The next thing you do is lock it up! [code]sudo apt-mark hold xserver-xorg-core[/code] I Hope it helps.[/quote] I was able to get in again and I replaced the libglx.so again and ran this. It seems to be alright now. Still really irritating.
Nexus8 said:


The next thing you do is lock it up!

sudo apt-mark hold xserver-xorg-core


I Hope it helps.


I was able to get in again and I replaced the libglx.so again and ran this. It seems to be alright now.
Still really irritating.

#24
Posted 10/09/2014 12:03 AM   
I was told to never do apt-get upgrade but apt-get dist-upgrade instead.
I was told to never do apt-get upgrade but apt-get dist-upgrade instead.

#25
Posted 12/21/2016 07:31 AM   
I don't know which is best to use, but here is something I found very useful in knowing what the differences are: [url]http://askubuntu.com/questions/194651/why-use-apt-get-upgrade-instead-of-apt-get-dist-upgrade[/url] One example I see of how this might be undesirable is from a Jetson TX1. If I use apt-get upgrade, then I see this message with updates held back: [code]The following packages have been kept back: gnome-software gnome-software-common libegl1-mesa libgl1-mesa-dri libwayland-egl1-mesa snapd ubuntu-core-launcher ubuntu-software 0 upgraded, 0 newly installed, 0 to remove and 8 not upgraded.[/code] If I start apt-get dist-upgrade, I see this instead: [code]The following package was automatically installed and is no longer required: ubuntu-core-launcher Use 'apt autoremove' to remove it. The following NEW packages will be installed: libllvm3.8 libsnapd-glib1 snap-confine snapd-login-service The following packages will be upgraded: gnome-software gnome-software-common libegl1-mesa libgl1-mesa-dri libwayland-egl1-mesa snapd ubuntu-core-launcher ubuntu-software 8 upgraded, 4 newly installed, 0 to remove and 0 not upgraded.[/code] If using Wayland for a GUI app, then this latter may break Wayland-dependent software, but will otherwise update packages which have fixes/updates previously held back. If I were to test something like this I'd probably first clone my Jetson, and then if the dist-upgrade is a problem I'd have a way to back out the changes (a backup copy is always a good idea even if not experimenting). You could of course keep track of package changes and try to back things out manually, but this would depend on the system functioning...and if something like video rendering broke, manual revert might not be too easy. Overall, it seems dist-upgrade is more invasive, but also more complete if you want things to be absolutely current.
I don't know which is best to use, but here is something I found very useful in knowing what the differences are:
http://askubuntu.com/questions/194651/why-use-apt-get-upgrade-instead-of-apt-get-dist-upgrade

One example I see of how this might be undesirable is from a Jetson TX1. If I use apt-get upgrade, then I see this message with updates held back:
The following packages have been kept back:
gnome-software gnome-software-common libegl1-mesa libgl1-mesa-dri libwayland-egl1-mesa snapd ubuntu-core-launcher ubuntu-software
0 upgraded, 0 newly installed, 0 to remove and 8 not upgraded.


If I start apt-get dist-upgrade, I see this instead:
The following package was automatically installed and is no longer required:
ubuntu-core-launcher
Use 'apt autoremove' to remove it.
The following NEW packages will be installed:
libllvm3.8 libsnapd-glib1 snap-confine snapd-login-service
The following packages will be upgraded:
gnome-software gnome-software-common libegl1-mesa libgl1-mesa-dri libwayland-egl1-mesa snapd ubuntu-core-launcher ubuntu-software
8 upgraded, 4 newly installed, 0 to remove and 0 not upgraded.


If using Wayland for a GUI app, then this latter may break Wayland-dependent software, but will otherwise update packages which have fixes/updates previously held back. If I were to test something like this I'd probably first clone my Jetson, and then if the dist-upgrade is a problem I'd have a way to back out the changes (a backup copy is always a good idea even if not experimenting). You could of course keep track of package changes and try to back things out manually, but this would depend on the system functioning...and if something like video rendering broke, manual revert might not be too easy. Overall, it seems dist-upgrade is more invasive, but also more complete if you want things to be absolutely current.

#26
Posted 01/02/2017 04:44 PM   
I update my JETSON TK1 using JETPACK3 and now it doesnt boot. The system runs and then shutsdown. I tried downgrading to various other versions but all fails. Please help.
I update my JETSON TK1 using JETPACK3 and now it doesnt boot. The system runs and then shutsdown. I tried downgrading to various other versions but all fails.

Please help.

#27
Posted 03/22/2017 10:50 PM   
Often it is just a case of video not being configured. Running and shutting down though is not common. Sometimes it is difficult to actually know what is going on if you don't have a serial console connected (if you get a serial cable settings are 115200 8N1...CTS/DTS flow control is best but software flow control also works). In your case you would see boot loader and other text logs and have more specific information about what went wrong right before it shut down. If you are watching the power lights go off, then that's a pretty solid indication it shut down, but just to verify, how do you know it shut down and that it wasn't just video failing? Btw, this original thread was for a time when packages might overwrite NVIDIA's libglx.so and break video...this has been fixed for quite some time, but other things can break video. FYI, I'd suggest starting a new thread rather than adding to this thread.
Often it is just a case of video not being configured. Running and shutting down though is not common. Sometimes it is difficult to actually know what is going on if you don't have a serial console connected (if you get a serial cable settings are 115200 8N1...CTS/DTS flow control is best but software flow control also works). In your case you would see boot loader and other text logs and have more specific information about what went wrong right before it shut down.

If you are watching the power lights go off, then that's a pretty solid indication it shut down, but just to verify, how do you know it shut down and that it wasn't just video failing?

Btw, this original thread was for a time when packages might overwrite NVIDIA's libglx.so and break video...this has been fixed for quite some time, but other things can break video. FYI, I'd suggest starting a new thread rather than adding to this thread.

#28
Posted 03/23/2017 12:06 AM   
It was working fine before the upgrade. With JETPACK 3 I see some weird lines on computer monitor, fan, LEDs light up and then after a while shutdown. I do not have a RS232 connector. Is there a way I can do without RS232? I have ordered one of these cables that are obsolete in market. But seriously, there is some flaw in the way JETPACK is configured. How should a newcomer know what is problem if you cant boot it. Goal of me getting this is to use for CUDA/cuDNN and not fixing the weird system related messages. Think.. Anyways, please let me know if there is a custom version that I can play with
It was working fine before the upgrade. With JETPACK 3 I see some weird lines on computer monitor, fan, LEDs light up and then after a while shutdown.

I do not have a RS232 connector. Is there a way I can do without RS232? I have ordered one of these cables that are obsolete in market.

But seriously, there is some flaw in the way JETPACK is configured. How should a newcomer know what is problem if you cant boot it. Goal of me getting this is to use for CUDA/cuDNN and not fixing the weird system related messages. Think..

Anyways, please let me know if there is a custom version that I can play with

#29
Posted 03/23/2017 07:31 PM   
A USB-to-RS232 is quite useful. The actual RS-232 and serial ports in general will be around a very long time...it's the host computer which typically does not have an RS-232 by default anymore. Everything "embedded" tends to still use the standard. Note that JetPack is a front end only, that it is a way to simplify many interdependent packaging options and also that it is a single interface which also include multiple hardware (JTK1, JTX1, JTX2). It's actually a simplification if everything works as expected. This is something of a side-effect when what was previously a specialized embedded device gained the power to act as a full desktop system and run a very wide range of software instead of just having a limited special purpose use...packaging got complicated. You can flash on command line with any x86_64 PC host and ignore JetPack and the GUI. Often failures are not from flash, but instead from package and network configuration following flash. If this is the case, then a simple command line flash may answer the question of whether failure is from some other stage. Until you have the serial console cable it's hard to know more. Pure command line flash does not add other packages, but if you are interested as a way of testing, download the driver package and sample rootfs here: [url]https://developer.nvidia.com/linux-tegra-r215[/url] Should this succeed you can still use JetPack later to manage individual packages. Make sure you have about 25GB of space available, e.g., from where you are going to unpack "df -H .". Then: [code] # ...unpack of driver package produces directory "Linux_for_Tegra", cd there... cd rootfs sudo tar xjf Tegra_Linux_Sample-Root-Filesystem_R21.5.0_armhf.tbz2 cd .. sudo ./apply_binaries.sh # ...make sure Jetson is in recovery mode and micro-B USB cable connected... sudo ./flash.sh -S 14580MiB jetson-tk1 mmcblk0p1[/code] This does take significant time, but if it succeeds, then your earlier issues were JetPack-related and the Jetson itself is working. If not, then there may be an issue with the Jetson itself. Incidentally, the original purpose of this thread involved Ubuntu packages overwriting a file which is actually from the apply_binaries.sh step. The apply_binaries.sh step equivalent directly on the Jetson would put the NVIDIA version of libglx file back in place. The sample rootfs is purely Ubuntu, the apply_binaries.sh is what adds hardware access and turns purely Ubuntu into L4T.
A USB-to-RS232 is quite useful. The actual RS-232 and serial ports in general will be around a very long time...it's the host computer which typically does not have an RS-232 by default anymore. Everything "embedded" tends to still use the standard.

Note that JetPack is a front end only, that it is a way to simplify many interdependent packaging options and also that it is a single interface which also include multiple hardware (JTK1, JTX1, JTX2). It's actually a simplification if everything works as expected. This is something of a side-effect when what was previously a specialized embedded device gained the power to act as a full desktop system and run a very wide range of software instead of just having a limited special purpose use...packaging got complicated.

You can flash on command line with any x86_64 PC host and ignore JetPack and the GUI. Often failures are not from flash, but instead from package and network configuration following flash. If this is the case, then a simple command line flash may answer the question of whether failure is from some other stage. Until you have the serial console cable it's hard to know more.

Pure command line flash does not add other packages, but if you are interested as a way of testing, download the driver package and sample rootfs here:
https://developer.nvidia.com/linux-tegra-r215

Should this succeed you can still use JetPack later to manage individual packages.

Make sure you have about 25GB of space available, e.g., from where you are going to unpack "df -H .". Then:
# ...unpack of driver package produces directory "Linux_for_Tegra", cd there...
cd rootfs
sudo tar xjf Tegra_Linux_Sample-Root-Filesystem_R21.5.0_armhf.tbz2
cd ..
sudo ./apply_binaries.sh
# ...make sure Jetson is in recovery mode and micro-B USB cable connected...
sudo ./flash.sh -S 14580MiB jetson-tk1 mmcblk0p1


This does take significant time, but if it succeeds, then your earlier issues were JetPack-related and the Jetson itself is working. If not, then there may be an issue with the Jetson itself.

Incidentally, the original purpose of this thread involved Ubuntu packages overwriting a file which is actually from the apply_binaries.sh step. The apply_binaries.sh step equivalent directly on the Jetson would put the NVIDIA version of libglx file back in place. The sample rootfs is purely Ubuntu, the apply_binaries.sh is what adds hardware access and turns purely Ubuntu into L4T.

#30
Posted 03/23/2017 08:03 PM   
Scroll To Top

Add Reply