JetPack 4.3: MESA-LOADER: failed to open swrast while in xrdp session

Autonomous Machines Jetson & Embedded Systems Jetson Nano
21

Gentleman, I’m experiencing the exact same problem.

Please let me know about any workarounds (i.e reversing libDRM to an older version works? which one?).

Thanks in advance!

ivan@nano:~$ glxinfo
name of display: localhost:10.0
MESA-LOADER: failed to open swrast (search paths /usr/lib/aarch64-linux-gnu/dri:\${ORIGIN}/dri:/usr/lib/dri)
libGL error: failed to load driver: swrast
X Error of failed request:  GLXBadContext
  Major opcode of failed request:  149 (GLX)
  Minor opcode of failed request:  6 (X_GLXIsDirect)
  Serial number of failed request:  25
  Current serial number in output stream:  24
22

export DISPLAY=:0 before running glxinfo?

23

It doesn’t work. :-(

ivan@nano:~$ echo $DISPLAY
localhost:10.0
ivan@nano:~$ export DISPLAY=:0
ivan@nano:~$ glxinfo
Error: unable to open display :0
24

@ivanocj

I think that the problem is related to the libraries:

libdrm-freedreno1 libdrm-nouveau2 libdrm-etnaviv1 libdrm-amdgpu1 libdrm-amdgpu1 
libdrm-tegra0     libdrm-radeon1  libdrm-dev      libdrm-common  libdrm2

The working version for me is the 2.4.97-1ubuntu1~18.04.1 but I couldn’t find a
repository to download them from.

I had to reinstall from scratch to find the right libraries and then you don’t have to update them
as I said in a previous post (#18).

Anyway, according to me the problem is in the applicative xrdp that probably should be recompiled with the updated libraries.

Stefano

1 Like
25

Sorry again but I really want know what is the exact step to reproduce issue… there are 4 people here asking about similar error but the causes look different.

I guess the purpose here is use gnome with xrdp setup and even in a headless case. Is that correct?

Not sure why everyone is trying glxinfo. As my previous comment, for any usecase that runs with X API, you need to configure env variable “DISPLAY”. And this variable is valid when xorg detects a screen.

For example, if I want to run glxinfo with no monitor.

  1. Boot up device without hdmi cable
  2. Disable gdm3 manually
sudo service gdm3 stop
  1. Run the X manually again.
nvidia@nvidia-desktop:~$ sudo X
  1. Tell the X which screen to use, see if xrandr can see this screen and run glxinfo.
nvidia@nvidia-desktop:~$ export DISPLAY=:0
nvidia@nvidia-desktop:~$ xrandr
Screen 0: minimum 8 x 8, current 640 x 480, maximum 32767 x 32767
HDMI-0 disconnected primary (normal left inverted right x axis y axis)
nvidia@nvidia-desktop:~$ glxinfo 
name of display: :0
display: :0  screen: 0
direct rendering: Yes
server glx vendor string: NVIDIA Corporation
server glx version string: 1.4
server glx extensions:
----it is too long so skip the rest---
26

Thanks Wayne!!!

To me it’s solved!!! Shame on me… very simple issue.

Gentleman, before we run any mesa-utils bin like glxgears, glxinfo, etc, if we have a headless setup boot(non-graphical multi-user) we must have X Server running as Wayne explained above:

ivan@nano:~$ sudo X

Open another terminal and

ivan@nano:~$ export DISPLAY=:0

Then works!

ivan@nano:~$ glxinfo
name of display: :0
display: :0  screen: 0
direct rendering: Yes
server glx vendor string: NVIDIA Corporation
server glx version string: 1.4
server glx extensions:
    GLX_ARB_context_flush_control, GLX_ARB_create_context,
    GLX_ARB_create_context_no_error, GLX_ARB_create_context_profile,
    GLX_ARB_create_context_robustness, GLX_ARB_fbconfig_float,
    GLX_ARB_multisample, GLX_EXT_buffer_age,
    GLX_EXT_create_context_es2_profile, GLX_EXT_create_context_es_profile,
    GLX_EXT_framebuffer_sRGB, GLX_EXT_import_context, GLX_EXT_libglvnd,
    GLX_EXT_stereo_tree, GLX_EXT_swap_control, GLX_EXT_swap_control_tear,
    GLX_EXT_texture_from_pixmap, GLX_EXT_visual_info, GLX_EXT_visual_rating,
    GLX_NV_copy_image, GLX_NV_delay_before_swap, GLX_NV_float_buffer,
    GLX_NV_robustness_video_memory_purge, GLX_SGIX_fbconfig, GLX_SGIX_pbuffer,
    GLX_SGI_swap_control, GLX_SGI_video_sync
client glx vendor string: NVIDIA Corporation
client glx version string: 1.4.

Now I can implement this:
https://medium.com/jit-team/building-a-gpu-enabled-kubernets-cluster-for-machine-learning-with-nvidia-jetson-nano-7b67de74172a

Thanks!!!
BR,
Ivan

2 Likes
27

I had a similar issue when I installed ros on docker and started rviz. This problem, as @WayneWWW says, is caused by a mixture of mesa and tegra libraries.

my problem note:

【Encountered problem】
Running glxgears in Xavier JetPack 4.3 Docker results in an error.

libGL error: No matching fbConfigs or visuals found
libGL error: failed to load driver: swrast
X Error of failed request:  GLXBadContext
  Major opcode of failed request:  154 (GLX)
  Minor opcode of failed request:  6 (X_GLXIsDirect)
  Serial number of failed request:  43
  Current serial number in output stream:  42

【Cause】
glxgears cannot refer to the appropriate nvidia library(libGL) because the path to /usr/lib/aarch64-linux-gnu/tegra is not passed in ldconfig.

【Solution】
Add /usr/lib/aarch64-linux-gnu/tegra to ldconfig path.
vi /etc/ld.so.conf.d/aarch64-linux-gnu.conf
/usr/lib/aarch64-linux-gnu/tegra

ldconfig

The important things are:
・Do not use mesa’s libGL. Check with ldd witch glxgears. If you have mesa’s libGL, you should uninstall it.
・The path to the tegra library is set in ldconfig. Check ldconfig -v | grep /usr/lib/aarch64-linux-gnu/tegra.

My docker case is different from Remote Desktop, but I think this error(libGL serial number is mismatched) is a library problem.

28

@WayneWWW

I guess the purpose here is use gnome with xrdp setup and even in a headless case. Is that correct?

Yes. My test case is only when I connect remotely with the xrdp client (headless or not).
Again local access (obviously not headless) has no problems whatsoever even
with all binary mesa-utils (glxinfo, glxgears, ecc…).

I have problems only with version 2.4.99-1ubuntu1~18.04.1 of the libraries:

libdrm-freedreno1 libdrm-nouveau2 libdrm-etnaviv1 libdrm-amdgpu1 libdrm-tegra0
libdrm-radeon1    libdrm-dev      libdrm-common   libdrm2

but now I’m starting to think that the problem is the xrdp client, that isn’t compatible
with that version of libraries.

Do you know how to test these libraries otherwise?

Thx for the support.
Stefano

29

@WayneWWW

[quote=“”]
… the problem is the xrdp client …
Sorry, I made a mistake, obviously is the xrdp server.

Stefano

30

I’m stuck at this same point too. Maybe my observations will help.

I recently loaded Jetpack 4.3 and ran through some of the hello word tutorials to make sure everything was working OK. All looks good.

I then got Nsight Eclipse edition running on my host Ubuntu 18.04.4 machine.
Following the “CUDA Development for Jetson with NVIDIA Nsight Eclipse Edition” tutorial, I created a boxfilter project from the Cuda Samples directory.

The project compiles fine and runs on the remote Nano but fails saying:
freeglut (/tmp/nsight-debug/boxTest): failed to open display ':0". (I tried other display values as well)

When I attempt to debug the program, I can single step to glutInit(argc, argv); On the next step(over) I get “[Inferior 1 (process 8603) exited with code 01]” with no specific info on what went wrong. This occurs whether the Nano is headless or not.

If I do log into the Nano locally, i can go to /tmp/nsight-debug and run boxTest directly. That opens up a window on the Nano and works fine.

However, if I SSH with MobaXterm from a Windows machine and try to run /tmp/nsight-debug/boxTest i get:

./boxTest Starting…

Loaded ‘./lenaRGB.ppm’, 1024 x 1024 pixels
GPU Device 0: “NVIDIA Tegra X1” with compute capability 5.3

MESA-LOADER: failed to open swrast (search paths /usr/lib/aarch64-linux-gnu/dri:$${ORIGIN}/dri:/usr/lib/dri)
libGL error: failed to load driver: swrast
Error: failed to get minimal extensions for demo
This sample requires:
OpenGL version 2.0
GL_ARB_vertex_buffer_object
GL_ARB_pixel_buffer_object

Ironically, I just found out that if I SSH from the Ubuntu host to the Nano and go to /tmp/nsight-debug, I can run boxTest and it works fine. A window open on the Nano and works fine.

So,
Running Nsight executable on Nano from Nsight on Ubuntu host fails.
Running the executable that Nsight created locally on the Nano works
SSH from the Ubuntu to the Nano and running the executable that Nsight created works.
SSH with MobaXtem from Windows and running the executable that Nsight created fails with:
MESA-LOADER: failed to open swrast

I hope this help someone figure out what wrong in the scenarios others have presented.

31

I am having similar issues trying to run tightvncserver on my freshly installed Xavier system. MESA-LOADER: failed to open swrast (search paths /usr/lib/aarch64-linux-gnu/dri:$${ORIGIN}/dri:/usr/lib/dri)
libGL error: failed to load driver: swrast

It is resulting in me not being able to get anything but a black screen on vnc sessions. I don’t want to use vino because I need displays that are not the :0 local display. It was all working just fine for me on a computer I built up with Jetpack 4.2.1 a month ago, but for some reason when I tried 4.2.1 again on a new computer, I am getting issues similar to what people are saying they see with 4.3.

32

Hello there,
I’ve got a similar issue (MESA -LOADER), with a distant connection using SSH (with MobaXterm or UBUNTU) on a jetson nano (18.04.4 LTS (GNU/Linux 4.9.140-tegra aarch64)).
I need displays that are not local (DISPLAY:0 will not do for me) to display screen such as rviz. Does anyone have a clue to what to do? I am a bit lost.
Thanks for your help.

33

Hi Alexander

I am facing the exact same problem as you describe.
Were you able to solve it?
Could you post the solution here? In the thread the solution seems to be missing.

Thank you.

34

Hi Jaume,

unfortunately I haven’t been able to solve it yet. Based on the discussion above it seems to be an issue related to one or more libraries on the Jetson Nano.
I ordered myself an HDMI dongle and I am using it in combination with an X11 session (which I am manually starting via startx in a ssh terminal session plus a VNC viewer on my MacBook).

  • Alexander
35

Recently I bought a new Jetson Nano and had the same swrast issue encountered. My new Jetson Nano is running on Jetpack 4.4. Curiously, I have another Jetbot and have never encountered any swrast issue with it. My Jebot is running on Jetpack 4.3 and has no package upgrade done before. It made me believe that it must be some new package which makes Mesa fail to work remotely. I therefore spent few days to dig out which package causes for the issue. What I did is to install Jetpack 4.3 on my new Jetson Nano and perform package upgrade one by one.

Finally I had the problematic package identified. It is “libdrm-amdgpu1” which causes for the issue. To fix the problem, I copied the old “/usr/lib/aarch64-linux-gnu/libdrm_amdgpu.so.1.0.0” from Jetpack 4.3 to my new Jetson Nano.

I am not sure if there will be any side effect but at least it fixes my remote X11 problem for the moment.

2 Likes
37

Could you please post the file online somewhere (google drive or mega.nz) - I would like to try your solution!

38

You may consider to install Jetpack 4.3 on a blank SD card and then copy the so from there. I believe it won’t take you too much time and it is more official.

1 Like
39

Hi all,

I’ve been looking at an issue related to the above on the XRDP pages.

https://github.com/neutrinolabs/xrdp/issues/1582

I think it’s the same issue as the above, so I thought I’d add a way to demonstrate it.

To summarise:-

  • The X display on the console appears to be working fine with Jetpack installed.
  • With Jetpack installed, GLX on tigervnc breaks. This prevents users creating GNOME desktops as GNOME requires GLX for remote displays.

Although XRDP can run with Xorg as a backend, this fault appears to be about the Xvnc server which stops working when Jetpack is installed. It’s nothing to do with the console X server running of display :0, and it’s not related directly to XRDP.

The following script demonstrates the problem. To run it, you’ll need to install tigervnc-standalone-server, mesa-utils, and (optionally) gnome-session-bin packages:-

#!/bin/bash

GLXINFO=/usr/bin/glxinfo
GNOME_CHECK=/usr/lib/gnome-session/gnome-session-check-accelerated
DISPLAY=:11

echo "- Checking X server"
xserver=$(which Xvnc)
if [[ -z $xserver || ! -x $xserver ]]; then
    echo "** Can't find Xvnc server" >&2
    exit 1
fi

ls -l $xserver
while [[ -h $xserver ]]; do
    xserver=$(readlink $xserver)
    ls -l $xserver
done

if [[ ! -x $GLXINFO ]]; then
    echo "** Please install $GLXINFO (Debian package mesa-utils)" >&2
    exit 1
fi


echo "- Starting X server on display :$DISPLAY"
xlog=$(mktemp /tmp/xlog.XXXXXXXXXX)
$xserver $DISPLAY -ac >$xlog 2>&1 &
xpid=$!

sleep 5
if $(kill -0 $xpid); then
    echo "  Server started OK. Querying server"
    export DISPLAY
    glxinfo -display $DISPLAY | sed -e '/GLX Visuals/,$d'
    if [[ -x $GNOME_CHECK ]]; then
	echo "- Checking GNOME acceleration"
        $GNOME_CHECK
        echo
        if [[ $? -eq 0 ]]; then
            echo "  GNOME accelaration is supported"
       else
            echo "  GNOME accelaration is not supported"
       fi
    else
	    echo "  Need $GNOME_CHECK (not installed)"
    fi
    kill $xpid
else
    echo " Server failed to start. Log follows:"
    cat $xlog
fi
wait

rm -f $xlog

I hope that’s relatively clear, and will allow someone with the correct hardware to debug the issue. There’s more info on the linked fault report.

40

Hi, just my two cents. I’ve discovered that issue happens when glxinfo’ing over SSH with X11 forwarding enabled, AFTER I update the suggested packages on a freshly installed Jetpack 4.3. Meaning that if I don’t update the packages apt suggests me to install after the first boot, I don’t have the problem. So, basically, since I relaized that, I never update my 4.3 Jetpack and use it stock. That way I don’t have to face this problem. However, if I install Jetpack 4.4, it’s already broken on a fresh install (no need to update to break it).

Whay library is responsible for this? I’d assume it’s some lib related to mesa. However, Ive too much stuff going on to be able to track that too. So, for me, I’m still avoiding 4.4 DP, hoping a future release will have it working as it should.

I have posted on another thread all the related information about mesa versions pre update and post update, maybe if someone is interested that could also help.

Thanks.
Regards.
Eduardo.

1 Like
41

Let me try to summarize:

There are two problems floating around in this thread: The first one is xrdp not working in Jetson Nano JetPack 4.4 - only in JetPack 4.3 while it is not upgraded at all. The other is mesa-utils not working in 4.4 when not working from the main console. The problems exhibit the same error message (in case of mesa-utils directly on the command line, in case of failing xrdp in syslog):

libGL error: MESA-LOADER: failed to open swrast (search paths /usr/lib/aarch64-linux-gnu/dri:$${ORIGIN}/dri:/usr/lib/dri)

Since the error messages appear to be the same, there is a non-zero possibility that those two problems are manifestations of the same root problem, but there is no proof of that.

Since IMHO the xrdp problem is the more severe problem because the Jetson Nano is typically run headlessly, let me focus on that. The problem is there regardless of whether a monitor is plugged into the HDMI output of the Jetson Nano or not. When trying to log in from remote (while logged out from the main console if plugged in), the connection is terminated by the Jetson Nano right after the credentials are entered.

First, @WayneWWW’s suggestion to add a “screen” section in the xorg.conf makes no difference for me. Second, @raymonlo’s suggestion to replace a single library (libdrm_amdgpu.so.1.0.0) with the one from 4.3 also made no difference for me either. Lastly, there is a workaround proposed by @sorlando961, which is to hold all the libdrm libraries:

This works fine as far as it goes and xrdp works even when upgrading existing packages. However, when attempting to “unminimize” the installation (to install packages that were missing from the original distro), unminimize complains

E: Unable to correct problems, you have held broken packages

which is because the held packages have unmet dependencies after an upgrade.

Hence, unfortunately, the workaround is not complete and leaves the system only partially functional.

Therefore, I am afraid, this still needs to get a real fix for the Jetson Nano to be fully functional, even though the urgency has been somewhat reduced by @sorlando961’s workaround.

Any ideas @WayneWWW???

Oh - and the mesa-utils work when logging into the Jetson Nano via xrdp or ssh -Y with the “held” libraries…