CentOS Question posted in
The official documentation can be found here.

Unable to open X display when trying to run google-chrome on Centos (Rhel 7.5)

I need to run Google Chrome remotely on a virtual machine using SSH. I do not want xforwarding – I want to utilize the GPU available on the vm. When I try running google-chrome I get following error:

[19615:19615:0219/152933.751028:ERROR:browser_main_loop.cc(1512)] Unable to open X display.

I’ve tried to setting my DISPLAY env value to various values:

export DISPLAY=localhost:0.0
export DISPLAY=127.0.0.1:0.0
export DISPLAY=:0.0

I’ve also tried replacing 0.0 in abowe examples with different values.

I have ForwardX11 no in /etc/ssh/sshd_config
I tried setting up target like this: 

systemctl isolate multi-user.target

When I try to run sudo lshw -C display i get folowing output:

   *-display
       description: VGA compatible controller
       product: Hyper-V virtual VGA
       vendor: Microsoft Corporation
       physical id: 8
       bus info: pci@0000:00:08.0
       version: 00
       width: 32 bits
       clock: 33MHz
       capabilities: vga_controller bus_master rom
       configuration: driver=hyperv_fb latency=0
       resources: irq:11 memory:f8000000-fbffffff
  *-display UNCLAIMED
       description: VGA compatible controller
       product: GM204GL [Tesla M60]
       vendor: NVIDIA Corporation
       physical id: 1
       version: a1
       width: 64 bits
       clock: 33MHz
       capabilities: pm msi pciexpress vga_controller bus_master cap_list
       configuration: latency=0
       resources: iomemory:f0-ef iomemory:f0-ef memory:41000000-41ffffff memory:fe0000000-fefffffff memory:ff0000000-ff1ffffff

I’ve tried to update my gpu drivers by:

wget https://www.nvidia.com/content/DriverDownload-March2009/confirmation.php?url=/tesla/375.66/nvidia-diag-driver-local-repo-rhel7-375.66-1.x86_64.rpm
yum -y install nvidia-diag-driver-local-repo-rhel7-375.66-1.x86_64.rpm

But after that I still see UNCLIMED next to my NVIDIA gpu.
Aby ideas?

Tags:

4

Answers


  1. 0

    You can try with Xvfb. it does not require additional hardware.

    Install Xvfb if you didn’t install it yet and do the following steps.

    sudo apt-get install -y xvfb

    Dependencies to make "headless" chrome/selenium work:

    sudo apt-get -y install xorg xvfb gtk2-engines-pixbuf
sudo apt-get -y install dbus-x11 xfonts-base xfonts-100dpi xfonts-75dpi xfonts-cyrillic xfonts-scalable

    Optional but nifty: For capturing screenshots of Xvfb display:

    sudo apt-get -y install imagemagick x11-apps

    Make sure that Xvfb starts every time the box/vm is booted:

    Xvfb -ac :99 -screen 0 1280x1024x16 &
export DISPLAY=:99

    Run Google Chrome

    google-chrome
    Login or Signup to reply.
  2. 0

    Okay guys. I found my problem after 2 hours of going crazy. My box was configured correctly. What you can NOT do, is ssh from one box, to another box, to this box and expect X11 forwarding to play nicely. Without tearing apart the entire network, I found that if I shelled over from the MAIN box to this box ( no double or triple ssh’ing) chrome comes right up as a regular user using CLI. So it was a matter of multiple shells from multiple boxes that made the display say it was set to NOTHING! Setting the display manually only complicates the problems. Once I shelled directly over to this box from the main outside box, my display was set to 10:0, which is first instance in my configuration. Don’t make this mistake, you will waste valuable time.

    Login or Signup to reply.
  3. 0

    I faced the same issue with WSL and Ubuntu. I have unininstalled/Reset the ubuntu. After that, I have executed the below command

    wsl --set-default-version 2

    then I installed again the Ubuntu, I didn’t get --no-sandbox issue or any issue.

    Hope this will use for someone.

    Login or Signup to reply.
  4. 0

    FWIW, I ran into this when using SSH to log into a Selenium chrome node in a Docker compose stack. Chrome would launch if I invoked it as root with sudo -u seluser google-chrome, but not if I logged in as seluser. The trick turned out to be that root had DISPLAY set to :99:0, and seluser didn’t have it set at all. If I set it explicitly (either from a seluser shell or from the docker compose exec command line) it worked.

    $ docker-compose exec -u seluser 
  selenium-chrome                  # or whatever your service is called
  /bin/bash
seluser@c02cda62b751:/$ export DISPLAY=:99:0
seluser@c02cda62b751:/$ google-chrome http://app.test:3000/home

    or

    $ docker-compose exec -u seluser -e DISPLAY=:99:0 
  selenium-chrome 
    google-chrome http://app.test:3000/home

    That :99.0 is undocumented, though, so if this isn’t working, you might try checking root‘s DISPLAY value with:

    docker-compose exec -u root selenium-chrome bash -c 'echo "${DISPLAY}"'
    Login or Signup to reply.
Please signup or login to give your own answer.

Back To Top
Search