apt-get update: Fixing When Packages Overwritten

Autonomous Machines Jetson & Embedded Systems Jetson TX2
1

I noticed on R27.1 that this combination overwrites NVDIA files (a dependency needs to be fixed):

sudo apt update
sudo apt-get upgrade

If you run this before and after and upgrade you’ll find an old error is back where libglx.so is overwritten (this will cause graphical mode to fail, but networking and serial console will still work). The relevant file is:

/usr/lib/xorg/modules/extensions/libglx.so

The fast/easy way is to just scp (or otherwise copy) driver package file “nv_tegra/nvidia_drivers.tbz2” to the Jetson’s “/” directory and unpack everything:

# From the Jetson...
cd /
sudo scp name@host:/where/ever/it/is/Linux_for_Tegra/nv_tegra/nvidia_drivers.tbz2 .
sudo tar xjf
# Verify:
sha1sum -c /etc/nv_tegra_release

You could just unpack the libglx.so file and put that back in place. Unpacking everything basically freshens all NVIDIA-specific files. It would be wise to simply copy the original “/usr/lib/xorg/modules/extensions/libglx.so” file somewhere safe before “apt-get upgrade”, then the one file could be put back in place and would be ready before any update.

NOTE: I do not recommend avoiding updates, updates are quite useful. Consider running this once you are prepared to put libglx.so back in place:

sudo apt update
sudo apt-get upgrade
sha1sum -c /etc/nv_tegra_release
# ...if failed, then do the fix steps listed previously...
# verify again as fixed with:
sha1sum -c /etc/nv_tegra_release
2

This is somewhat unfortunate.
The same issue was present for the jetson tk1.
https://devtalk.nvidia.com/default/topic/775070/jetson-tk1/-l4t-r19-x-notice-on-apt-get-upgrade-libglx-so-corruption/post/4309848/#4309848

I assume that ‘sudo apt-mark hold xserver-xorg-core’ still works and is sufficient?
Is that the case?

Thanks and best wishes,
Martin

3

I did not verify which package does the overwrite. Probably it is the same xserver-xorg-core, and marking that for hold would do the job (the file being overwritten is the same so unless the package normally producing this file changed it would still be xserver-xorg-core). I would guess a future L4T release will fix that dependency.

4

this does not solve my problem.
Instead running your commands gives me:

nvidia@tegra-ubuntu:/$ sudo scp name@host:/where/ever/it/is/Linux_for_Tegra/nv_tegra/nvidia_drivers.tbz2
usage: scp [-12346BCpqrv] [-c cipher] [-F ssh_config] [-i identity_file]
           [-l limit] [-o ssh_option] [-P port] [-S program]
           [[user@]host1:]file1 ... [[user@]host2:]file2

if i include the " ." at the end it gives me

nvidia@tegra-ubuntu:/$ sudo scp name@host:/where/ever/it/is/Linux_for_Tegra/nv_tegra/nvidia_drivers.tbz2 .
ssh: Could not resolve hostname host: Name or service not known

this does not work at all

nvidia@tegra-ubuntu:/$ sudo tar xjf
tar: Old option 'f' requires an argument.
Try 'tar --help' or 'tar --usage' for more information.
5

See:
[url]After apt-get upgrade for Jetson Tx2 with JetPack 3.2 error with libglx - Jetson TX2 - NVIDIA Developer Forums

The longer answer is that there are two copies of this file on your system, and sometimes an external mesa package can overwrite one of them. The symbolic link takes advantage of the copy which is still correct, scp does the same thing by copy of the file to the Jetson from the driver package and sample rootfs. Normally nvidia_drivers.tbz2 is copied onto the sample rootfs and this puts the file in place within the sample rootfs prior to flash…either way does the same thing.

Note that “tar” with the “f” argument requires naming a file…which would be the path to the nvidia_drivers.tbz2 file from the driver package (which is something JetPack might download if told to).

Before scp can work ssh must work…which means you need the network address of the Jetson.

6

I was running this code on the jetson. (I am currently only working on it with a display)

"
1.# From the Jetson…

"

this comment made me think I needed to run the code directly from the jetson…

I am not sure why, but after a reboot everything seemed to be ok.
If I run “sha1sum -c /etc/nv_tegra_release” there are no more errors, so I guess the system solved this by its own.

Any suggestions how and why?

7

Your steps put the file back in place…reboot was required to see the change.