Return of the dreaded Cannot open /dev/tty0 (Permission denied) issue on modern Ubuntu! #1550
Comments
|
Here is my /etc/X11/xorg.conf: |
|
And here is my /etc/X11/xrdp/xorg.conf: |
|
If you see this in the log |
|
That was all the hint I needed to fix it! When you install the Nvidia Binary drivers it also dropped in /usr/share/X11/xorg.conf.d/20-nvidia.conf, contents were: Removed that file and XRDP immediately started working. |
|
I'm happy to answer more questions about this, otherwise you can resolve. |
|
If we can get /usr/lib/xorg/modules/drivers/nvidia_drv.so working with xorgxrdp I think that's pretty big. It means we can use prime offloading to make use of the NVidia OpenGL. It works already with modesetting / glamor drivers so I'm hopeful. |
|
Then we need to figure out why there are permission issues here, as a start. These articles look like they have promising information:
It looks like the problem here might be that XRDP isn't using vtX. When I have other virtualized remote desktop systems that do work with Nvidia, they all have commands that look like this to load Xorg:
but my XRDP command uses:
Is there a reason why XRDP doesn't load using the virtual terminal system? (vtX) |
|
|
|
@metalefty any update for newer xorg version support |
|
Hi @Nexarian I've been looking at a similar issue in #2010 where a load of the I know you've been looking into this area with Jay. Is there anything at this point you'd like to add to the above, or is the best solution currently to stop the hardware driver (modesetting/nvidia/whatever) from loading? Thanks for any info. |
|
Hi @matt335672! Thanks for reaching out. I feel like I'm often learning about how these systems work in the same way physicists learn using a particle accelerator, by smashing things about and investigating what cracks open, but I'll give you what I know and my recommendations: First, some definitions?
Next, here's what I know so far:
To conclude, both Glamor and "nvidia_hack" allow for the driver files to be directly loaded into the Xorg session without superuser permissions, and allow for direct access to the hardware. That's what Optimus is trying to do here, but to be sure we should do a scientific "remove and test" solution to see which file in the config directory of the affected system is really the culprit, and analyze further from there. Without special provisions to load whatever driver is being targeted, the xorgxrdp driver fails with this modesetting error, which is ultimately misleading. Finally, we should use Does this help? |
|
Thanks for the info @Nexarian From what I can tell from the X server sources, if certain modules are loaded, the X server will try to open the 'console', which is indeed a physical or virtual terminal. This is done by a call to The code which makes that determination is here:- https://gitlab.freedesktop.org/xorg/xserver/-/blob/master/hw/xfree86/common/xf86Init.c#L413-436 When the It's always possible of course I'm completely misreading the code here! I've tried to be more scientific about this with the OP for the issue, but frankly I wasn't getting anywhere, and config management was not working at all. However:-
I'm unable to reproduce the original fault here sadly. I don't have any hardware which seems to make this happen. I'll bear the above in mind however, and next time I get a similar fault to triage (it shouldn't be long!), I'll be better prepared. I hope the above is at least of some interest. |
|
Just had the same error after Debian 12 upgrade. Somehow the new lines in But the comment gave me a idea. A |
|
@Nexarian - can we close this one now? |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
As requested from my comment in #1546, I keep seeing this issue with the latest versions of xrdp and xorgxrdp (built from source) on Ubuntu 18.04 with Gnome 3.32.
I had XRDP working with Ubuntu 18.04 on Gnome 3.32 (Yes, I recognize Gnome 3.32 doesn't come standard with Ubuntu 18.04, but I wanted fractional scaling!), but then made the following changes:
/opt/VirtualGL/bin/vglserver_config(I also liked that CRD worked with VirtualGL, and I'm not sure XRDP does)....
Enjoyed CRD until my company blocked it due to some sort of nebulous security justification.
Now, I tried to go back to XRDP but I can't, because of the Cannot open /dev/tty0 (Permission denied) error. If memory serves, it was something vglserver_config did that broke it, but running the "uninstall" command on it doesn't fix things, so that might not be it.
I have tried all sorts of variants of xserver-xorg-legacy. I tried uninstalling dbus-user-session and installing dbus-x11 (for a while, both were installed SxS). I've tried the chmod 0660 trick on dev/tty* but that only moves the error down the pipe so that it can't access psaux for the mouse.
Still nothing. I'd love to help test patches or debug in any way I can. I would love to have XRDP back, because otherwise I have to suffer with NoMachine (my company's supported solution barf)
XVNC works (it's glacially slow), but xorgxrdp doesn't. I have both xrdp and xorgxrdp building from source at the head of their respective github repos.
Here is the log from .xorgxrdp.10.log:
The text was updated successfully, but these errors were encountered: