[GH-ISSUE #2351] OpenGL does not work even with --noprofile (NixOS)

gitea-mirror commented

2026-05-05 08:13:41 -06:00

Owner

Originally created by @neirenoir on GitHub (Jan 20, 2019).
Original GitHub issue: https://github.com/netblue30/firejail/issues/2351

I am not sure why this is happening, but Firefox just refuses to play WebGL content, even if it is run with --noprofile.

Steps to reproduce

Launch Firefox with Firejail
Go to some website which uses WebGL. I use https://threejs.org/examples/#webgl_interactive_voxelpainter
Receive an error message informing that WebGL is not supported in your browser.

Extra information

When running Firefox through a console, it spews the following:

* Refused to create native OpenGL context because of blacklist entry: 
* Exhausted GL driver options.
JavaScript warning: https://threejs.org/build/three.js, line 22284: Error: WebGL warning: getContext: Disallowing antialiased backbuffers due to blacklisting.
JavaScript warning: https://threejs.org/build/three.js, line 22284: Error: WebGL warning: <SetDimensions>: Refused to create native OpenGL context because of blacklist entry: 
JavaScript warning: https://threejs.org/build/three.js, line 22284: Error: WebGL warning: <SetDimensions>: Failed to create WebGL context: WebGL creation failed:

I have double checked my Firefox settings and all seems clear. WebGL is enabled, the gfx.blacklist option that's often mentioned does not even exist anymore (or at least on my build), tried force-enabling WebGL with webgl.force-enable, but it just refuses to run. It just works whenever I run Firefox without Firejail, so I know it can run just well.

Version info

firejail version 0.9.56
Firefox version 64.0.2
NixOS 19.03
Mesa 18.3.1, amdgpu

Might be a NixOS specific issue, but I do not know why it wouldn't work even after setting --noprofile, while working just well when run without firejail. If nobody else is experiencing the issue, I will take it to their bug tracker.

Originally created by @neirenoir on GitHub (Jan 20, 2019). Original GitHub issue: https://github.com/netblue30/firejail/issues/2351 I am not sure why this is happening, but Firefox just refuses to play WebGL content, even if it is run with --noprofile. ### Steps to reproduce 1. Launch Firefox with Firejail 2. Go to some website which uses WebGL. I use https://threejs.org/examples/#webgl_interactive_voxelpainter 3. Receive an error message informing that WebGL is not supported in your browser. ### Extra information When running Firefox through a console, it spews the following: ``` * Refused to create native OpenGL context because of blacklist entry: * Exhausted GL driver options. JavaScript warning: https://threejs.org/build/three.js, line 22284: Error: WebGL warning: getContext: Disallowing antialiased backbuffers due to blacklisting. JavaScript warning: https://threejs.org/build/three.js, line 22284: Error: WebGL warning: <SetDimensions>: Refused to create native OpenGL context because of blacklist entry: JavaScript warning: https://threejs.org/build/three.js, line 22284: Error: WebGL warning: <SetDimensions>: Failed to create WebGL context: WebGL creation failed: ``` I have double checked my Firefox settings and all seems clear. WebGL is enabled, the gfx.blacklist option that's often mentioned does not even exist anymore (or at least on my build), tried force-enabling WebGL with webgl.force-enable, but it just refuses to run. It just works whenever I run Firefox without Firejail, so I know it can run just well. ### Version info - firejail version 0.9.56 - Firefox version 64.0.2 - NixOS 19.03 - Mesa 18.3.1, amdgpu Might be a NixOS specific issue, but I do not know why it wouldn't work even after setting --noprofile, while working just well when run without firejail. If nobody else is experiencing the issue, I will take it to their bug tracker.

gitea-mirror

2026-05-05 08:13:41 -06:00

closed this issue
added the
graphics

notabug
labels

gitea-mirror commented

2026-05-05 08:13:45 -06:00

Author

Owner

@SkewedZeppelin commented on GitHub (Jan 20, 2019):

If nobody else is experiencing the issue

I think I've seen this before, but it could've been a conflict with something else

@SkewedZeppelin commented on GitHub (Jan 20, 2019): > If nobody else is experiencing the issue I think I've seen this before, but it could've been a conflict with something else

gitea-mirror commented

2026-05-05 08:13:46 -06:00

Author

Owner

@chiraag-nataraj commented on GitHub (Jan 20, 2019):

Hmm, I don't seem to be seeing the issue with a completely new profile under Debian. Does it happen on your end if you try with a completely new firefox profile? You can create a temporary one using my private-profile.sh script here if you don't want to clutter your default firefox install with extra profiles.

@chiraag-nataraj commented on GitHub (Jan 20, 2019): Hmm, I don't seem to be seeing the issue with a completely new profile under Debian. Does it happen on your end if you try with a completely new firefox profile? You can create a temporary one using my `private-profile.sh` script [here](https://github.com/chiraag-nataraj/firejail-profiles) if you don't want to clutter your default firefox install with extra profiles.

gitea-mirror commented

2026-05-05 08:13:47 -06:00

Author

Owner

@neirenoir commented on GitHub (Jan 30, 2019):

I have tried the same procedure on a different computer, with the same distro, different Firefox version, and different graphical drivers (noveau), and the result is the same. I will take this to the NixOS bug tracker, but it would be nice to know what does firejail do behind the scenes when set as --noprofile, which I assume are the "defaults" of firejail.

@chiraag-nataraj Wouldn't any profile be more likely to cause errors than --noprofile, due to being less lax?

@neirenoir commented on GitHub (Jan 30, 2019): I have tried the same procedure on a different computer, with the same distro, different Firefox version, and different graphical drivers (noveau), and the result is the same. I will take this to the NixOS bug tracker, but it would be nice to know what does firejail do behind the scenes when set as --noprofile, which I assume are the "defaults" of firejail. @chiraag-nataraj Wouldn't any profile be more likely to cause errors than --noprofile, due to being less lax?

gitea-mirror commented

2026-05-05 08:13:48 -06:00

Author

Owner

@SkewedZeppelin commented on GitHub (Jan 30, 2019):

Firejail by default applies the default.profile which has many restrictions.
--noprofile has minimal restrictions: process namespace + restricted /boot, etc.

@SkewedZeppelin commented on GitHub (Jan 30, 2019): Firejail by default applies the default.profile which has many restrictions. --noprofile has minimal restrictions: process namespace + restricted /boot, etc.

gitea-mirror commented

2026-05-05 08:13:49 -06:00

Author

Owner

@chiraag-nataraj commented on GitHub (Feb 7, 2019):

@shirona

Wouldn't any profile be more likely to cause errors than --noprofile, due to being less lax?

I meant a firefox profile, not a firejail profile (confusing, I know). firejail profiles enable restrictions on what the program can do. firefox profiles are to segregate user data (so you can have different sets of extensions, different preferences, and so on). I asked if this happens with a new firefox profile.

@chiraag-nataraj commented on GitHub (Feb 7, 2019): @shirona > Wouldn't any profile be more likely to cause errors than --noprofile, due to being less lax? I meant a _firefox_ profile, not a _firejail_ profile (confusing, I know). `firejail` profiles enable restrictions on what the program can do. `firefox` profiles are to segregate user data (so you can have different sets of extensions, different preferences, and so on). I asked if this happens with a new _firefox_ profile.

gitea-mirror commented

2026-05-05 08:13:49 -06:00

Author

Owner

@PalinuroSec commented on GitHub (Feb 7, 2019):

i have the same issue with firefox 65 and firejail 0.9.58 (debian testing)

@PalinuroSec commented on GitHub (Feb 7, 2019): i have the same issue with firefox 65 and firejail 0.9.58 (debian testing)

gitea-mirror commented

2026-05-05 08:13:50 -06:00

Author

Owner

@neirenoir commented on GitHub (Feb 9, 2019):

@chiraag-nataraj Yes, it happens in a new profile as well. In fact, I have recently discovered it is happening on all OpenGL applications in general, except Steam games (I suspect the reason is it uses a weird chroot in NixOS that remaps a lot of stuff). This should be reproducible by running firejail --noprofile glxgears. An interesting detail is that Vulkan applications do work.

The command above prints the following before closing the window (which lasts for a frame and never gets to render the gears):

name of display: :0
Error: couldn't find RGB GLX visual or fbconfig

@PalinuroSec Could you try running firejail --noprofile glxgears?

@neirenoir commented on GitHub (Feb 9, 2019): @chiraag-nataraj Yes, it happens in a new profile as well. In fact, I have recently discovered it is happening on all OpenGL applications in general, except Steam games (I suspect the reason is it uses a weird chroot in NixOS that remaps a lot of stuff). This should be reproducible by running `firejail --noprofile glxgears`. An interesting detail is that Vulkan applications do work. The command above prints the following before closing the window (which lasts for a frame and never gets to render the gears): ``` name of display: :0 Error: couldn't find RGB GLX visual or fbconfig ``` @PalinuroSec Could you try running `firejail --noprofile glxgears`?

gitea-mirror commented

2026-05-05 08:13:51 -06:00

Author

Owner

@PalinuroSec commented on GitHub (Feb 14, 2019):

@shirona
┌─[palinuro@parrot]─[~]
└──╼ $firejail --noprofile glxgears
Parent pid 11104, child pid 11105
Child process initialized in 38.28 ms
Error: couldn't get an RGB, Double-buffered visual

Parent is shutting down, bye...

p.s.
we fixed the firefox bug by disabling `noexec ${HOME} which is pretty weird but mandatory in order to have firefox working again with webgl or with DRM-powered websites like netflix

@PalinuroSec commented on GitHub (Feb 14, 2019): @shirona ┌─[palinuro@parrot]─[~] └──╼ $firejail --noprofile glxgears Parent pid 11104, child pid 11105 Child process initialized in 38.28 ms Error: couldn't get an RGB, Double-buffered visual Parent is shutting down, bye... p.s. we fixed the firefox bug by disabling `noexec ${HOME} which is pretty weird but mandatory in order to have firefox working again with webgl or with DRM-powered websites like netflix

gitea-mirror commented

2026-05-05 08:13:52 -06:00

Author

Owner

@neirenoir commented on GitHub (Apr 14, 2019):

This still doesn't work in firejail 0.9.58.2. @netblue30, any ideas as to what could be interfering with OpenGL? Tried @PalinuroSec's fix with noexec $HOME in Firefox, but it didn't work. Truth is no OpenGL program works but Steam, but then again, Steam has its own SteamRT and a full blown FHS chroot in NixOS, so it may be something else.

I have been told it may have to do with /run/opengl-driver not being accessible, but it is fully accessible under any profile, let alone --noprofile, so I don't know what else could it be.

@neirenoir commented on GitHub (Apr 14, 2019): This still doesn't work in `firejail 0.9.58.2`. @netblue30, any ideas as to what could be interfering with OpenGL? Tried @PalinuroSec's fix with `noexec $HOME` in Firefox, but it didn't work. Truth is no OpenGL program works but Steam, but then again, Steam has its own SteamRT and a full blown FHS chroot in NixOS, so it may be something else. I have been told it may have to do with `/run/opengl-driver` not being accessible, but it is fully accessible under any profile, let alone `--noprofile`, so I don't know what else could it be.

gitea-mirror commented

2026-05-05 08:13:52 -06:00

Author

Owner

@neirenoir commented on GitHub (Apr 25, 2019):

Alright, ran some tests today to find out why did Steam run OpenGL just fine despite being firejailed. I found the answer to be... really simple. I'm sorry for not having noticed earlier that the issue was that all firejail was doing was not inheriting/expunging LD_LIBRARY_PATH. In NixOS, LD_LIBRARY_PATH comes preconfigured to point to the path of the OpenGL libraries, so the issue was as simple as that. Steam ran alright because it has some set up scripts that re-set this variable later on in the launch process.

So... yeah, sorry for wasting your time like this. Gonna close this issue, as it is more of a problem with NixOS, and not even that.

@neirenoir commented on GitHub (Apr 25, 2019): Alright, ran some tests today to find out why did Steam run OpenGL just fine despite being firejailed. I found the answer to be... really simple. I'm sorry for not having noticed earlier that the issue was that all firejail was doing was not inheriting/expunging `LD_LIBRARY_PATH`. In NixOS, `LD_LIBRARY_PATH` comes preconfigured to point to the path of the OpenGL libraries, so the issue was as simple as that. Steam ran alright because it has some set up scripts that re-set this variable later on in the launch process. So... yeah, sorry for wasting your time like this. Gonna close this issue, as it is more of a problem with NixOS, and not even that.

gitea-mirror referenced this issue

2026-05-05 09:43:32 -06:00

[GH-ISSUE #5751] ssh-agent: eval hangs without --deterministic-shutdown #3082

gitea-mirror referenced this issue

2026-05-05 09:43:32 -06:00

[GH-ISSUE #5751] ssh-agent: eval hangs without --deterministic-shutdown #3082

Rows
Columns

[GH-ISSUE #2351] OpenGL does not work even with --noprofile (NixOS) #1568

Steps to reproduce

Extra information

Version info