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

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

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

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

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.

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

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…

Jump into this thread.

For this “failed to open swrast” issue, could you try to link the libdrm.so.2 to libdrm.so.2.4.0?

/usr/lib/aarch64-linux-gnu/libdrm.so.2 → /usr/lib/aarch64-linux-gnu/libdrm.so.2.4.0.

3 Likes

@WayneWWW

I am experiencing the same problem and tried updating the symlink:

cd /usr/lib/aarch64-linux-gnu 
sudo ln -sf libdrm.so.2 libdrm.so.2.4.0

I then rebooted but still when I login using xrdp the nvidia logo shows for less than a second and the session is disconnected.

I installed jetpack 441:
jetson-nano-4gb-jp441-sd-card-image.zip
From https://developer.nvidia.com/embedded/learn/get-started-jetson-nano-devkit#write

Is this the right image? I’ve updated Ubuntu to the latest packages.

I’d really like to use the Nano Headless if at all possible.

Thanks,
Al

@al17

The symlink command you pasted is wrong. Using your command will link the libdrm.so.2.4.0 → libdrm.so.2…

SOLVED!!!

Hi Wayne, you are perfectly right, the ln command expects target and link and not vice versa, so @al17’s command will not work.

I have updated the symlink as you suggest and I have now
libdrm.so.2 → libdrm.so.2.4.0

After reboot, the MESA issue failed to load swrast is fully solved. I can run glxgears but also other OpenGL programs that previously failed.

My use case is the same as many people in this thread - I am running Jetson Nano headless and log into it using xrdp.
Had login issues with gnome, resolved first by installing XFCE4, probably after your fix gnome would work as well, but I am quite ok with xfce and will not be changing it in the nearest future.

Thank you for the symlink suggestion!

1 Like

Creating the link libdrm.so.2 → libdrm.so.2.4.0 solves the problem temporarily until the next time ldconfig runs (which will be triggered by e.g. an apt-get install).

The problem seems to be that the link libdrm_nvdc.so → tegra/libdrm.so.2 will cause ldconfig to overwrite libdrm.so.2 with link to libdrm_nvdc.so.

To solve this permanently, I removed the link libdrm_nvdc.so → tegra/libdrm.so.2, and then ran ldconfig:

sudo rm /usr/lib/aarch64-linux-gnu/libdrm_nvdc.so
sudo ldconfig

This created the link libdrm.so.2 → libdrm.so.2.4.0.

Of course this could potentially result in other kinds of failures, but I have not experienced any yet.

2 Likes

I had the same problem. And it’s solved with @qwertypanda 's post. My work settings are:

  1. target: NX production module on CTI Quark board, headless, JetPack 4.5, L4T 32.5.
  2. host PC: laptop with Linux 18.04.
  3. Since the target is headless, I installed NoMachine to open the desktop of the NX. Xfce4 is installed on NX as a desktop.

When I run Cuda sample oceanFFT, I hit the libGL error, fixed with re-link the libdrm.so as said above.
Now I encounter a new error as following:

$ ./oceanFFT
NOTE: The CUDA Samples are not meant for performance measurements. Results may vary when GPU Boost is enabled.

[CUDA FFT Ocean Simulation]

Left mouse button - rotate
Middle mouse button - pan
Right mouse button - zoom
‘w’ key - toggle wireframe
[CUDA FFT Ocean Simulation]
GPU Device 0: “Xavier” with compute capability 7.2

CUDA error at oceanFFT.cpp:296 code=999(cudaErrorUnknown) “cudaGraphicsGLRegisterBuffer(&cuda_heightVB_resource, heightVertexBuffer, cudaGraphicsMapFlagsWriteDiscard)”
corrupted size vs. prev_size
Aborted (core dumped)

A graphic window opened and closed briefly.
In this case, is this a side effect of re-link the libdrm.so or something else with remote desktop? If anyone has the solution, please help.

Thanks.

Hi stuart-xu -

Have you contacted our Tech Team? If you fill out our Support Form, your team will help you troubleshoot and get you up and running.

Let me know if you have any questions!
Jacki

Hi WayneWWW, Just re-installed Jetson Nano Developer Kit SD Card Image 4.5.1 2021/02/24 from the scratch and faced the same issue - “libGL error: MESA-LOADER: failed to open swrast”. To reproduce the issue:

sudo apt install xvfb mesa-utils
Xvfb :99 -screen 0 1600x1200x24 &
export DISPLAY=:99
glxinfo
name of display: :99
libGL error: 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
...

Is there any workaround? When the issue will be fixed completely? Thanks!

Scroll back few comments and you will see it.

Already tried - this won’t fix the issue.

What did you try? Is the symlink the one you want now?

I’ve tried again and it works! Thanks! What libdrm_nvdc.so is used for? sudo rm -f /usr/lib/aarch64-linux-gnu/libdrm_nvdc.so also fix the issue, but probably produce some other issues…

hey there. I also facing the same problem when i launch some file to run the jetson-inference commands on jetbot gui using nvidia jetson nano 2gb DK and here is the error:
libGL error: 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: 154 (GLX)
Minor opcode of failed request: 6 (X_GLXIsDirect)
Serial number of failed request: 39
Current serial number in output stream: 38

and any one help me I need to figure out

Do you get the same error with other OpenGL applications like glxgears?

Have you tried this suggestion from above?