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

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

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.

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.

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.

I was told to never do apt-get upgrade but apt-get dist-upgrade instead.

I don’t know which is best to use, but here is something I found very useful in knowing what the differences are:

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:
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.

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.

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.

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

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:

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.