Launcher installation fails on Ubuntu Linux

I am trying to install the Launcher on an Ubuntu Linux server (18.04.5 LTS (Bionic Beaver)) running in an AWS cloud environment. It crashes on takeoff with the following error:

$ ./omniverse-launcher-linux.AppImage
The futex facility returned an unexpected error code.Aborted (core dumped)

Any suggestions what the problem is or where I can find more information?

Hello michael.seager,

Thank you for posting, I will bring your issue to the proper channels for review.
Thank you for your patience.

Here’s the topic on GitHub about similar problems with Electron:

It seems that you can try to set a DISPLAY environment variable to fix the issue.

@michael.seager -
what ASW instance type did you use?
what GUI was installed?
could you tar up the ~/.nvidia-omniverse/logs and send them?

Hi Mirice –

The original problem that I reported was a futex error. After your previous suggestion I realized that I had to install an X server on my laptop, and now I get a little further: I no longer get the futex error, I now get a login screen that hangs indefinitely after I enter my email address as the userid – it never even asks for a password.

To your specific questions:

This is a t2.2xlarge Ubuntu instance running the in the AWS Gov West cloud.

I connect to the server with putty. I am running Xming on my laptop and have putty configured to send X11 traffic to my laptop. With this configuration, my putty session automatically sets the DISPLAY variable and that solves the futex error.

The log is only a few lines so I will paste it here rather than tar’ing it:

[2021-04-06 17:08:09.572] [error] (node:4213) electron: The default of contextIsolation is deprecated and will be changing from false to true in a future release of Electron. See for more information

[2021-04-06 17:08:11.019] [info] Can’t access the /home/ubuntu/.config/omniverse-launcher/data/installers.json file: ENOENT: no such file or directory, access ‘/home/ubuntu/.config/omniverse-launcher/data/installers.json’

[2021-04-06 17:08:11.029] [info] Can’t access the /home/ubuntu/.nvidia-omniverse/config/privacy.toml file: ENOENT: no such file or directory, access ‘/home/ubuntu/.nvidia-omniverse/config/privacy.toml’

[2021-04-06 17:08:15.118] [info] Running production web server.

[2021-04-06 17:08:17.021] [info] HTTP endpoints listening at http://localhost:33480

[2021-04-06 17:09:07.159] [info] Login URL opened.

[2021-04-06 17:09:07.163] [info] Waiting for login result…

At that point it hangs indefinitely – I have tried it several times, and waited between 10 minutes and a couple hours with no further progress.


Hi @michael.seager - so i think i might have reproduced your issue. Yes it will hang at that phase, but will spawn a Chrome browser window to complete the sign in. It took a long time for that window to appear via this setup. But eventually it did.

  1. Make sure you have chrome installed
  2. Make sure chrome is default

Think this sort of solves your issue. But notice that you used a t2 AWS instance. This will not work. You need an instance that supports RTX or T4 (g4dn AWS instance type) And need the T4 drivers installed. You need the “Quadro Virtual Workstation” AWS offering. At the moment i have not actually tried to spin on of these up and attach via your XMING method.

Is your goal to use a AWS instance due to not having a RTX card in your laptop? Basically a remote workstation with laptop as just GUI front end? Also is there a need for ubuntu? would a windows AWS instance work for you and you remote desktop into it from laptop?

Hi Mirice –

This is lots of good information. I will back up a bit.

Our goal is to build an environment for engineering collaboration that resides entirely within the security of a cloud environment. We were under the impression that NVIDIA recommended Linux servers rather than Windows for a production environment.

We are perfectly willing to switch to a Windows server in the AWS cloud if that is the recommended configuration.


Hi @michael.seager - Ok, think i am getting a better picture now of your goals. But maybe a few back and forth exchanges might help me.

  1. The Omniverse Nucleus - you want to host this in the cloud, right? This is so you can share/collaborate these resources between developers in various locations.
  2. For the content manipulation (Create app for example), Each developer would have their own local hardware (PC/GPU). These would not be in the cloud. Or am i wrong on this?

Our goal is to create a secure environment in which engineers can collaborate on product development. We are trying to use AWS as a central repository for CAD models; engineers should be able to upload new models to this environment, and view them individually or as a team, but not extract the files from the environment. We want a server to host Omniverse and workspaces that have the capability to use Omniverse to view CAD models. Users will be able to connect to a workspace from their laptop but will not be able to download files from it to their laptop.

With all that said, we don’t really care about Windows vs Linux, so we can go with whatever is easier/better and I welcome your suggestions in that regard.



The Omniverse Nucleus component for cloud based storage/usage that meets your needs will be available soon. This is a Linux docker based solution that you would run on AWS. The current workstation Nucleus (windows) Is only for local area networks and is not recommended for production situations.

But Nucleus itself is a collaboration infrastructure that will allow DCC tools (like Create, Revit, etc.) to access the DB to retrieve USD files for manipulation and rendering. The files that are retrieved from Nucleus within the cloud could be saved locally on the accessing server. Nucleus itself will not perform any gate keeping as to if the file is to be just rendered or saved.

If I understand your use case, you would like to manipulate/render the files with some set DCC tools (and possibly save back to AWS) but not allow these users to save the files on the remote workstations. In addition, the remote workstation users may not have RTX hardware and thus need to render the files in the cloud and just have a GUI interface back to the remote workstations/laptops.

Here is a possible solution

  1. Create a AWS instance that is a Linux based server and install the future Omniverse Enterprise Nucleus
  2. Create some AWS instances (windows based) that have RTX GPUs (AWS g4dn). Lets call these jump instances
  3. The AWS Nucleus server would be locked down to only communicate with the AWS jump instances. Thus the files in Nucleus cannot be accessed outside of AWS and files cannot be viewed or saved. But the jump instances can access the files.
  4. On the jump instances, install Omniverse Create or other DCC tools that have Omniverse support (Revit, Maya, etc.)
  5. Your remote users RDP to the AWS jump instances and have full GUI. The jump instances have direct access to the GPUs and the Nucleus DB. Configure the jump instances to only have RDP port open back to the workstations and windows config not to allow RDP remote device storage access.

Thus people assigned to the jump servers can view (or edit if you give proper permissions) the files. But they cannot retrieve the files back the server that starts the RDP. They could save the file to the jump station file system, but could not move that file out of the cloud.

We can refine/reduce above based on actual DCC tools needed. Some tool will allow remote streaming and solve your save issues.