That does not help. Absolutely do NOT run "chmod -R 755 /etc/xdg" as
this will set the execution bit on any files in that directory or
subdirectories, that's completely incorrect.
--
You received this bug notification because you are a member of Ubuntu-X,
which is subscribed to xinit in Ubuntu.
h
Check the /etc/xdg permissions (if not unusual, check other etc
directories).
A "kid induced power shortage" (daughter :D) broken the directory's
permissions (random numbers instead of "drwxr-x---").
After "sudo chmod -R 755 /etc/xdg", everything worked getting a rid of
the msg "xf86OpenConsole:
I opened up https://bugs.launchpad.net/ubuntu/+source/xinit/+bug/1876119
which is a duplicate of this bug.
We are celebrating the fourth anniversary of this bug. Perhaps xinit
should be removed from Ubuntu if it's not a maintained package anymore?
This bug is still affecting me on latest 20.04 di
Does install the suid-root wrapper allow for any user to run an X
server? This seems a little too open if so, as it seems better to allow
only either root, or the user logged into the console to run the server,
IMHO.
--
You received this bug notification because you are a member of Ubuntu-X,
whic
Update to #30 Upon further investigation
On 14.04, the files in /usr/bin are binaries.
-X is a suid wrapper binary
-Xorg is the actual binary
On 16.04, they are scripts.
-X is a link to Xorg
-Xorg is a script, calling the actual executables in /usr/lib/xorg/.
It seems the Xorg script in /usr/bin
#29 does not seem to be correct, at least in my case. Installed xserver-
xorg-legacy first, and checked. No 'X' wrapper binary present. After
installing other xserver packages, this is what I have.
Output of ls -la /usr/bin | grep X
On 14.04:
-rwsr-sr-x 1 root root9532 Dec 9 2014 X
lr
no, the workaround should be to install xserver-xorg-legacy, which
installs the suid-root wrapper again
--
You received this bug notification because you are a member of Ubuntu-X,
which is subscribed to xinit in Ubuntu.
https://bugs.launchpad.net/bugs/1562219
Title:
Unprivileged xinit wont sta
The workaround I used to fix the original problem as stated by the
person who opened this ticket was to do the following:
chmod ug+s /usr/lib/xorg/Xorg
It seems in Ubuntu 14.04 the Xorg xserver binary has permissions of:
-rwsr-sr-x 1 root root 10192 Dec 9 2014 /usr/bin/X
so by running the abo
This bug drove me batty until I found this. Making a Nextcloud appliance with
Ubuntu Server 16.04 as the OS and I couldn't install a gui. Tried xfce, lxde,
and lxqt to no avail. Re-installed, tried again, and nothing.
Post #14 worked for me but a little different.
startxfce4 -- :1 vt1
Is the pr
As for my post #14,
1) It was tested on Intel HD Graphics 3000 (only open-source drivers are
available for this hardware)
2) One should launch a separate dbus instance when starting X. Without
it, steam client, especially in big picture, mode stutters:
xinit /usr/bin/dbus-launch --exit-with-sess
Uh, I wish I could edit my 2 posts above out. My problem was simple.
After installing from the mini.iso, I was running an installation script
that has a command of the form:
sudo apt-get install --no-install-recommends package1 package2 package3
. . .
It always worked before. But one of those pac
I should add that this probably the 5th or 6th time I've installed a
16.04 system on this machine and failed to get startx to work properly.
I have another such that I haven't scrapped yet that WILL eventually
start openbox in response to startx. But it takes a long time and
results in my being log
Me too. Under 16.04, 64 bit, with openbox, startx (or xinit) as user
fails. Sudo startx gives me a console with a tiny font, so apparently it
starts X but not Openbox. I'd explore that further and probably find how
to start Openbox, but I don't want to run X as root anyway. I just tried
sudo as a d
Ubfan1's comments (#19, #20 and #21) are not relevant to the bug as it
has been described. We were already aware that X sessions could be
started on the same vt as the command line that they're launched from.
Further complications from the Nvidia driver would seem to be a separate
bug?
As the bug
Comment 14 works with Nvidia when using the nouveau driver, but not the Nvidia
driver 367.57 (black screen). Starting an xterm allows you to run other
things, even unity.
Using the nouveau driver, login to vt2 and run:
xinit /usr/bin/xterm -- :1 vt2
Result is a white background xterm, fully
On another 16.04 machine without Nvidia, comment 14 produced a working
display. The Nvidia driver causing the problem on the first machine was
367.57.
--
You received this bug notification because you are a member of Ubuntu-X,
which is subscribed to xinit in Ubuntu.
https://bugs.launchpad.net/bu
Ubuntu 16.04, Nvidia Quadro 1000m, #14 allow the X server to run, applications
may be launched (xterm, then xclock) and they appear in ps, keyboard input to
the xterm works, but the display is totally black. No errors are in the
~/.local/share/xorg/Xorg.1.log file (a failure does show:
xf86Enab
I can confirm that #14 works for me also, however it doesn't provide me
with with the functionality that I require.
It would be useful to know whether this is intended behavior, or an
unintended bug.
Updated bug title to reflect comment #14, and added a paragraph to the
top of the bug description
** Summary changed:
- xinit will not work as non-root.
+ Unprivileged xinit wont start in unallocated vt
--
You received this bug notification because you are a member of Ubuntu-X,
which is subscribed to xinit in Ubuntu.
https://bugs.launchpad.net/bugs/1562219
Title:
Unprivileged xinit wont
19 matches
Mail list logo
