No GUI after upgrade to L4T R21.1 - libglx.so seems to be OK

Hello. This is my first post in the forum. I have hard time trying to upgrade my Jetson to L4T R21. My current setup is R19.3 with Grinch kernel 19.3.6, all packages updated to latest versions. Everything works correctly.

I’m trying to upgrade to R21.1 without reflashing the whole system. I have spent a lot of time to install and configure everything, and I really want to avoid doing it all again.

So, I’ve downloaded L4T package from the web to my Jetson and I’ve run apply_binaries exactly as the documentation says. The result is that:

  • I have no GUI (black screen), I can access only the text console,
  • sha1sum reports that all files are OK,
  • libglx.so is in place, ldd shows that it's OK,
  • Xorg and lightdm logs indicate that loading GLX (or NV-GLX) module failed; the last line in lightdm log is "Loading extension GLX", the next one should be "Loading extension NV-GLX", but the X server returns 1 and quits.

I’ve read many posts on the “black screen” issue, but it seems that my problem is different.
Is there anything else I could do to upgrade to R21 and avoid reflasing everything?
I didn’t flash the kernel from R21, I understand from reding other posts that R21 should work with my current kernel.

BTW, I reverted to R19 with its apply_binaries and the system works fine. But I really need CUDA 6.5.

The issue is still the same, but the method of running apply_binaries directly on Jetson causes the failure to not be noted by the “OK” list. When you install those binaries directly this way you also update the /etc/nv_tegra_release file…sha1sum tells you if the files on the system match the nv_tegra_release listing. That listing is now for R21.1. So if your system is R21.1 the files are correct.

Your system is still R19. The libglx.so must be the one the X server was compiled against…a more accurate error would explain libglx.so does not match X, that instead it matches R21’s X and X requires R19’s libglx.so. Thus going back to the R19.3 files “fixes” X…X and libglx.so are back in sync.

There are a series of files involved in an upgrade. You are better off doing a clean install, and you could possibly make a backup. Options and difficulties for restore depend on where your customizations were and whether you still have a system.img file. In your R19.3 host, subdirectory of the flash.sh script “bootloader”, do you still have “system.img”? Some work would be involved, but are you interested in backing up and then full R21.1 flash+selective restore?

Thanks for answering, but I must say I’m even more confused than before, especially with “your system is still R19”. Here is how I see this, correct me if I’m wrong.

The “system” consists of the filesystem (derived from Ubuntu 14.04) and the Linux 4 Tegra package (which is essentially a firmware). When you flash the whole system, you unpack the filesystem on the host, “apply” files from L4T onto it and then flash the system (together with the kernel) to the Jetson.

In my case, I have a “R19” system which, after upgrading packages from apt repositories, should be compatible with R21 filesystem. In other words, files that are different in R19 and R21 filesystems, should be either in R21 L4T or in system repositories. Now, if I apply binaries from L4T R21 onto my system, I should have a R21 system.

I agree that libglx and X server versions should be compatible. The thing is, my Xorg version is exactly the same as in R21 filesystem (I’ve checked this, it’s 1.15.1).

So, the only thing I didn’t do is flashing the kernel from R21. I didn’t do it because the Grinch kernel developer said that it works with R21 and I was afraid that I won’t be able to revert to the older system if things go wrong.

I have already had to reflash the system from scratch once and since this time the number of installed packages and configuration changes is much higher, I would really like to avoid this. So perhaps I’ll get some suggestions here.

I believe there is more change in going from R19 to R21 than just the files of apply_binaries. For the system to be compatible with libraries being interchangeable there would have been only a minor version change from R19.3 to R19.4…instead we have major version change all the way from 19 to 21.

Should the X have been compiled against a GLX that has not changed ABI or features, sure, these files would be interchangeable…but libraries and other files are compiled against other libraries and files (just look at the list shown on “ldd” of the X executable…and then on each ldd of a lib that shows up…and to each lib showing up to via ldd of each other lib)…including dependencies on firmware, and firmware in apply_binaries is also likely altered. I guess I just trust that nVidia went from major version 19 to major version 21 for a reason. And yes, perhaps the kernel is the only difference…in which case the system calls are what X and the libraries are dependent upon which is no longer compatible with old files. nVidia would have to name every single dependency if you really want to know a list of upgrading manually.

Incidentally, arguments to flash.sh relative to boot loader cause some changes as well, possibly to rootfs (especially when u-boot is used). Default flash.sh arguments were changed from R19 to R21…you would have to manually give every single command line argument under R21 to match R19 if you want to be sure just this one issue didn’t change things. Or in the case of manual upgrade, you would have to manually install each change caused by flash.sh.

It was worth a try to use the apply_binaries output. The acid test though is in the results of what happened…loss of GUI. If you use u-boot you can try changing the kernel to R21 as well without much effort, but it sounds like you have fastboot (which requires flash to change).