In searching for the cause, I found that the failure of 2D acceleration
must be due to a user configuration problem rather than a permissions
problem.
The system partition and thus the roots folder were newly created, the
/home/ partition was taken over from the previous installation
icious
permissions, needs clarification
to be marked as done.
This means that you claim that the problem has been dealt with.
If this is not the case it is now your responsibility to reopen the
Bug report if necessary, and/or fix the problem forthwith.
(NB: If you are a system administrator an
Timo Aaltonen pushed to branch upstream-unstable at X Strike Force / vulkan /
glslang
Commits:
d03da06a by otakuto at 2018-08-06T18:16:20Z
Remove execute permissions
- - - - -
dae0b0a5 by otakuto at 2018-08-06T18:25:35Z
Add shebang
- - - - -
228e964b by John Kessenich at 2018-08-14T03:37:59Z
Timo Aaltonen pushed to branch debian-unstable at X Strike Force / vulkan /
glslang
Commits:
d03da06a by otakuto at 2018-08-06T18:16:20Z
Remove execute permissions
- - - - -
dae0b0a5 by otakuto at 2018-08-06T18:25:35Z
Add shebang
- - - - -
228e964b by John Kessenich at 2018-08-14T03:37:59Z
erm(2) and iopl(2) from
>their kernel entirely and X still ran fine (with
>KMS) once it was told to continue (ignore the
>error).
>
> 3. it looks like Xorg itself merged a fix[3][4] to
> ignore hardware I/O port error, based on comments[5]
>by keithp.
>
>
Your message dated Tue, 27 Oct 2015 17:05:47 +
with message-id <e1zr7gx-0004xf...@franck.debian.org>
and subject line Bug#802544: fixed in xorg-server 2:1.17.3-1
has caused the Debian Bug report #802544,
regarding Xorg.wrap move to xorg-legacy broke X startup (permissions)
to be marked a
sed on comments[5]
by keithp.
Why can't '-nohwaccess' flag be added to the X server
(I'll handle device node permissions myself)?
Alternatively, why not just have X drop privs via
setreuid() after it does whatever it thinks it has to
with the hardware?
Also, how does systemd-logind do this? It
On Wed, Oct 21, 2015 at 16:10:50 -0700, Scott Mcdermott wrote:
> Julien Cristau on 2015/10/21 +0200 @20:48:56:
> > > xserver-xorg-core:amd64 (1.17.2-1.1, 1.17.2-3)
> > >
> > > This upgrade has broken X startup for me. Here is how
> > > I start X (as ordinary user):
> > >
> > > exec setsid
On Tue, Oct 20, 2015 at 14:46:44 -0700, Scott Mcdermott wrote:
> Package: xserver-xorg-legacy
> Version: 2:1.17.2-3
> Severity: grave
>
> I recently did an upgrade of X, which broke it on my machine.
> Here are old (working) and new (broken) versions that apt-get
> installed, as shown in
Julien Cristau on 2015/10/21 +0200 @20:48:56:
> > xserver-xorg-core:amd64 (1.17.2-1.1, 1.17.2-3)
> >
> > This upgrade has broken X startup for me. Here is how
> > I start X (as ordinary user):
> >
> > exec setsid env -i \
> > ...
> > X :0 vt63 \
>
> So one solution is to
odesetting was originally
implemented in the kernel.
Looking at the ChangeLog, I saw that /usr/bin/X was actually a
wrapper, which was moved to xserver-xorg-legacy. Ok then:
Install: xserver-xorg-legacy:amd64 (1.17.2-3)
Problem 1: after upgrade, permissions bad on device
/usr/lib/xorg/Xorg
Your message dated Sun, 13 Feb 2011 06:47:15 +
with message-id e1povjn-lh...@franck.debian.org
and subject line Bug#581338: fixed in xorg 1:7.6+3
has caused the Debian Bug report #581338,
regarding x11-common sets wrong permissions for Xwrapper.config
to be marked as done.
This means
no security-sensible information in this file, unlike, say,
/etc/shadow which has to have restrictive permissions, -- this file
only contains two settings used by X setuid wrapper, which are also
available from debconf database.
It is not usually a problem to have that file mode 0600
On Thu, Jul 10, 2008 at 16:04:40 -0400, Jeff Green wrote:
Today I upgraded my lenny install with the latest and had to reboot (for
other
reasons), but when I tried to login to my normal account I, it returned
me fairly quickly to the login screen. Quick research showed that
session
Julien Cristau wrote:
On Thu, Jul 10, 2008 at 16:04:40 -0400, Jeff Green wrote:
Today I upgraded my lenny install with the latest and had to reboot (for other
reasons), but when I tried to login to my normal account I, it returned
me fairly quickly to the login screen. Quick research
On Fri, Jul 11, 2008 at 10:07:07 -0400, Jeffrey B. Green wrote:
Yes, I am using xdm.
[EMAIL PROTECTED]:/home/jeff[888] ps -lC xdm
F S UID PID PPID C PRI NI ADDR SZ WCHAN TTY TIME CMD
1 S 0 6897 1 0 80 0 - 1942 rt_sig ? 00:00:00 xdm
1 S 0 6954 6897 0 80 0 - 2525 wait ? 00:00:00 xdm
The
.
I can start up a session as root which seems to confirm the permissions
notion.
I would also upgrade this bug to *important*.
-jeff
-- System Information:
Debian Release: lenny/sid
Architecture: powerpc (ppc)
Kernel: Linux 2.6.24-1-powerpc
Locale: LANG=C, LC_CTYPE=C (charmap=ANSI_X3.4-1968
administrator
(administrator, Debian Bugs database)
---BeginMessage---
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Package: xterm
Version: 208-3.1
Severity: normal
Tags: sid
The newest xterm set the wrong permissions on tty:
ikki:~ ls -l `tty`
crw--w--w- 1 klaus ethgen 136, 9 2006-01-25 22:50 /dev/pts
Your message dated Mon, 26 Feb 2007 20:50:06 +0100
with message-id [EMAIL PROTECTED]
and subject line #198397: Startup performance problem due to /tmp/.ICE_unix
permissions
has caused the attached Bug report to be marked as done.
This means that you claim that the problem has been dealt
:
/tmp/.ICE-unix is supposed to be created by /etc/init.d/x11-common at
startup. Is any of you able to reproduce this problem recently?
Yeah I think we can probably close this. If you deliberately remove it
and don't reboot then it won't be created with the right permissions but
there isn't
Processing commands for [EMAIL PROTECTED]:
severity 198397 important
Bug#198397: Startup performance problem due to /tmp/.ICE_unix permissions
Severity set to `important' from `normal'
merge 198397 298770
Bug#198397: Startup performance problem due to /tmp/.ICE_unix permissions
Bug#298770
Hi Loic,
About 2 years ago, you reported a bug to the Debian BTS regarding the
permissions of the X config file being overwritten. Did you reproduce
this problem recently? If not, I will close this bug in the next weeks.
Thanks,
Brice
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED
Hi,
on my system, bootclean script is executed in runlevels 1-5. And that is
wrong, as I have just discovered.
So the bug I have reported is not problem with x11-common, but with upgrade
from some former version of initscripts.
Sorry, you can close the bug.
Martin Kourim
--
To UNSUBSCRIBE,
Your message dated Fri, 17 Mar 2006 18:44:15 +0200
with message-id [EMAIL PROTECTED]
and subject line [EMAIL PROTECTED]: Bug#356867: x11-common: /tmp/.ICE-unix is
not created with right permissions after returning from single-user mode]
has caused the attached Bug report to be marked as done
Package: x11-common
Version: 6.9.0.dfsg.1-4
Severity: normal
Hi,
/tmp/.ICE-unix is deleted by bootclean script during entering
single-user mode (telinit 1), but is not recreated during returning back
to original runlevel.
It's because /etc/init.d/x11-common script is executed only in
runlevel S,
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Am Do den 26. Jan 2006 um 1:00 schrieb Thomas Dickey:
I believe this is the same problem as #349142.
Yes, its the same. I didn't find this Bug in the list.
A small note:
As I know (not absolutely true) it is not the job of the terminal to set
the
On Wed, Jan 25, 2006 at 11:20:15PM +0100, Klaus Ethgen wrote:
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Package: xterm
Version: 208-3.1
Severity: normal
Tags: sid
The newest xterm set the wrong permissions on tty:
ikki:~ ls -l `tty`
crw--w--w- 1 klaus ethgen 136, 9 2006-01-25 22
Package: xserver-xfree86
Version: 4.3.0.dfsg.1-6
Severity: normal
Hi,
It seems that when you dpkg-reconfigure xserver-xfree86, the
/etc/X11/XF86Config-4 file might be replaced by a newer version. When
this happens, the mode of the file is reset to 600, ie:
bee# ls -l
-pre1v4 with no previous version of x installed.
I also installed KDE from unstable.
I was unable to login as a normal user using KDM. So, I tried
~$ startx
-bash: startx: command not found
After some searching, I finally checked the permissions on
/usr/X11R6/bin and found:
~# ls
KDE from unstable.
I was unable to login as a normal user using KDM. So, I tried
~$ startx
-bash: startx: command not found
After some searching, I finally checked the permissions on
/usr/X11R6/bin and found:
~# ls -l /usr/X11R6
total 16
drwx--2 root root 4096
KDM. So, I tried
~$ startx
-bash: startx: command not found
After some searching, I finally checked the permissions on
/usr/X11R6/bin and found:
~# ls -l /usr/X11R6
total 16
drwx--2 root root 4096 Nov 11 10:23 bin
drwxr-xr-x3 root root 4096 Nov 11 09:14
Hello,
I am wondering, why the permissions for /usr/X11R6/bin have to be like this
topsi:/usr/X11R6# ls -l
total 20
drwx--2 root root 8192 Nov 8 20:12 bin
drwxr-xr-x3 root root 4096 Nov 8 16:18 include
drwxr-xr-x4 root root 4096 Nov 8 19:08
[EMAIL PROTECTED]
Subject: xserver-mach64: Mucks up the permissions on tty device
To: [EMAIL PROTECTED]
X-Mailer: bug 3.2.1
Package: xserver-mach64
Version: 3.3.3.1-7
Severity: normal
Note: This is possibly a problem across all X servers, but since I can only
test the Mach64 server, I'm filing
[EMAIL PROTECTED]
Subject: xserver-mach64: Mucks up the permissions on tty device
To: [EMAIL PROTECTED]
X-Mailer: bug 3.2.1
Package: xserver-mach64
Version: 3.3.3.1-7
Severity: normal
Note: This is possibly a problem across all X servers, but since I can only
test the Mach64 server, I'm filing
Processing commands for [EMAIL PROTECTED]:
tags 192229 + fixed
Bug#192229: xfree overwrites new driver with old each upgrade
There were no tags set.
Tags added: fixed
tags 192229 + pending
Bug#192229: xfree overwrites new driver with old each upgrade
Tags were: fixed
Tags added: pending
quit
tags 192299 + fixed
Bug#192299: octave-forge_2003.04.28-3(hppa/unstable): FTBFS: bad permissions
There were no tags set.
Tags added: fixed
tags 192299 + pending
Bug#192299: octave-forge_2003.04.28-3(hppa/unstable): FTBFS: bad permissions
Tags were: fixed
Tags added: pending
thanks
Stopping
On Wed, Nov 06, 2002 at 03:09:26AM -0500, Branden Robinson wrote:
On Tue, Nov 05, 2002 at 04:04:19PM -0800, Chris Waters wrote:
So, when I tried to run startx, I got a complaint that the permissions
on /tmp/.X11-unix were suspicious. Turns out that the permissions
were fine (drwxrwxrwt
On Tue, Nov 05, 2002 at 04:04:19PM -0800, Chris Waters wrote:
So, when I tried to run startx, I got a complaint that the permissions
on /tmp/.X11-unix were suspicious. Turns out that the permissions
were fine (drwxrwxrwt), but the dir was owned by aaron:aaron,
rather than root:root.
There's
On Wed, Nov 06, 2002 at 03:09:26AM -0500, Branden Robinson wrote:
On Tue, Nov 05, 2002 at 04:04:19PM -0800, Chris Waters wrote:
So, when I tried to run startx, I got a complaint that the permissions
on /tmp/.X11-unix were suspicious. Turns out that the permissions
were fine (drwxrwxrwt
is a user-space X server).
So, when I tried to run startx, I got a complaint that the permissions
on /tmp/.X11-unix were suspicious. Turns out that the permissions
were fine (drwxrwxrwt), but the dir was owned by aaron:aaron,
rather than root:root. But the XFree86 server simply refused to
work
is a user-space X server).
So, when I tried to run startx, I got a complaint that the permissions
on /tmp/.X11-unix were suspicious. Turns out that the permissions
were fine (drwxrwxrwt), but the dir was owned by aaron:aaron,
rather than root:root. But the XFree86 server simply refused to
work
In [EMAIL PROTECTED]
Will Newton [EMAIL PROTECTED] wrote:
Direct rendering is only working for root on my system (unstable/4.1.0). The
permissions for the DRI device files are:
/dev/dri:
drwxrwx---2 root root 4096 Aug 1 15:22 dri
/dev/dri/*:
crw-rw1 root
Direct rendering is only working for root on my system (unstable/4.1.0). The
permissions for the DRI device files are:
/dev/dri:
drwxrwx---2 root root 4096 Aug 1 15:22 dri
/dev/dri/*:
crw-rw1 root root 10, 63 Aug 1 15:22 card0
glxinfo as non-root:
[EMAIL
). The
permissions for the DRI device files are:
/dev/dri:
drwxrwx---2 root root 4096 Aug 1 15:22 dri
/dev/dri/*:
crw-rw1 root root 10, 63 Aug 1 15:22 card0
glxinfo as non-root:
[EMAIL PROTECTED]:~$ glxinfo
name of display: :0.0
libGL error
On Thursday 02 Aug 2001 2:33 am, you wrote:
If you want to be able to access the dri by a normal user you need to
either create a dri group or open the premissions up to everybody with a
chmod -R 666 /dev/dri
Thanks. Are there plans to create a dri group by default on Debian systems in
the
Christian Hammers [EMAIL PROTECTED] writes:
After upgrading to X4.0 (well done Brandon)
uh-oh. The name is Branden, not Brandon.
I always get the warning insecure permission/ownership on
/tmp/.X11-unix when starting gdm. After chown'ing from root:gdm
to root:root it works. Is this a
On Wed, Aug 02, 2000 at 08:52:40AM +0200, Marcelo E. Magallon wrote:
debs. These debs are for testing purposes and uncovering bugs.
Braden gets mightly pissed off (and rightly so) if he gets duplicate
or it's-already-fixed kind of reports, which is the case now.
Err, these were just one day
Hello
After upgrading to X4.0 (well done Brandon) I always get the warning
insecure permission/ownership on /tmp/.X11-unix when starting gdm.
After chown'ing from root:gdm to root:root it works. Is this a problem
with the new X or with the new gdm? (I don't know who creates this dir
in /tmp)
48 matches
Mail list logo
