On 13/09/2024 21:09, Pierre Willaime wrote:
I do not think it was related to non-free-firmware repository (Here is
my sources.list below)
deb http://deb.debian.org/debian bookworm main contrib non-free
non-free-firmware
It seems repositories are properly configured. In general however "apt
Le 11/09/2024 à 17:55, Max Nikulin a écrit :
grep -r system.conf /usr/share/dbus-1/
/usr/share/dbus-1/system.conf: ignore_missing="yes">/etc/dbus-1/system.conf
I do not have this file as well. I suggest Pierre to compare config
files of live and installed environments.
I recommend to read
On 11/09/2024 22:22, Greg Wooledge wrote:
On Wed, Sep 11, 2024 at 17:16:37 +0200, Pierre Willaime wrote:
systemctl status dbus.service shows dbus is not active ("failed") and I have
this message
Failed to start message bus: Circular inclusion of file
'/etc/dbus-1/system.conf'
hobbit:~$ gr
On Wed, Sep 11, 2024 at 17:16:37 +0200, Pierre Willaime wrote:
> systemctl status dbus.service shows dbus is not active ("failed") and I have
> this message
>
> Failed to start message bus: Circular inclusion of file
> '/etc/dbus-1/system.conf'
Curious. I have nothing that references that fil
Le 09/09/2024 à 04:56, Max Nikulin a écrit :>
Have you tried to boot from a live media? It should help to
determine if your problem is caused by unsupported upgrade path.
Yes. It is booting and working fine on a debian stable live usb.
Are there any errors, warnings, or suspicious messages in
On 09/09/2024 03:48, Pierre Willaime wrote:
Thanks. My user was *not* member of the 'input' group.
I made the change but it does not fix my issue (startx returns still an
error, see my other email).
Have you tried to boot from a live media? It should help to determine if
your problem is caus
On 08/09/2024 15:41, Jörg-Volker Peetz wrote:
Maybe your account is missing some authorizations.
What's the output of `id`? Is your account member of the groups 'video'
and 'input'?
Thanks. My user was *not* member of the 'input' group.
I made the change but it does not fix my issue (startx r
On 07/09/2024 23:32, Dan Ritter wrote:
Try
sudo dpkg-reconfigure xserver-xorg-legacy
and if that doesn't work, edit /etc/X11/Xwrapper.config
(and read the man page for it)
Thanks.
I tried to select "Root Only" (to restore old behavior) or "Anybody" when
reconfiguring xserver-xorg-legacy.
T
Maybe your account is missing some authorizations.
What's the output of `id`? Is your account member of the groups 'video' and
'input'?
Regards,
Jörg.
Pierre Willaime wrote:
> Hi,
>
> After upgrading from Strech to Booworm (I know: not recommended to jump
> versions), I have some trouble to start X server.
>
> startx returns this error:
>
> "Xf86EnableIO: failed to enable I/O ports -03ff (Operation not
> permitted)".
Stretch to Buster to
> my workstation's hostname is the same as my login
> username, which is (obviously) also the name of my home directory.
> And yet, I've never seen this problem before.
> So, there are definitely a few more variables involved in this one.
To reproduce, run xauth list $(hostname -f):0 from a direct
On Thu 31 Mar 2022 at 07:30:14 (-0400), Greg Wooledge wrote:
> On Wed, Mar 30, 2022 at 10:27:25PM -0700, Larry Doolittle wrote:
> > I seem to have rediscovered Debian bug 889720
> > xauth crashes when directory name matches host name
> > https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=889720
> >
On Wed, Mar 30, 2022 at 10:27:25PM -0700, Larry Doolittle wrote:
> I seem to have rediscovered Debian bug 889720
> xauth crashes when directory name matches host name
> https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=889720
> (Feb 2018)
>
> So, nothing to do with the Bullseye upgrade.
> I must h
I seem to have rediscovered Debian bug 889720
xauth crashes when directory name matches host name
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=889720
(Feb 2018)
So, nothing to do with the Bullseye upgrade.
I must have created that directory-matching-hostname in the
process of setting up for t
Larry Doolittle composed on 2022-03-30 19:31 (UTC-0700):
> Felix Miata wrote:
>> Is the problem avoided if you login via a display manager (gdm, sddm,
>> lightdm,
>> etc.) instead of using startx?
> Beats me. I don't have any software like that installed.
You could install one. Try LightDM.
Felix -
Felix Miata wrote:
> Is the problem avoided if you login via a display manager (gdm, sddm, lightdm,
> etc.) instead of using startx?
Beats me. I don't have any software like that installed.
Would they run xauth before or after cd'ing to my home directory?
- Larry
P.S. Sorry about b
Larry Doolittle composed on 2022-03-30 08:57 (UTC-0700):
> The xauth segfault is definitely real and
> a problem for me.
Is the problem avoided if you login via a display manager (gdm, sddm, lightdm,
etc.) instead of using startx?
--
Evolution as taught in public schools is, like religion,
Esteemed Debian experts and maintainers -
On Sun, Mar 27, 2022 at 11:26:37PM -0700, Larry Doolittle wrote:
> On Sun, Mar 27, 2022 at 10:45:03PM -0700, Larry Doolittle wrote:
> > I just upgraded my first machine from 11.2 to 11.3.
> > xauth fails in the context of startx.
> Workaround: create an em
Esteemed Debian experts and maintainers -
On Sun, Mar 27, 2022 at 10:45:03PM -0700, Larry Doolittle wrote:
> I just upgraded my first machine from 11.2 to 11.3.
> xauth fails in the context of startx.
> Message is
> xauth: timeout in locking authority file /home/[redacted]/.Xauthority
> both in
John Goerzen writes:
> But sddm doesn't work. In fact, when it starts, it causes my monitor to
> go "no signal". Oddly, though, if I can log in blindly, then once I hit
> enter after putting in my password, KDE will come up and work like it
> should.
>
> I also tried lightdm and xdm. Both of t
On Mon, Feb 28 2022, Felix Miata wrote:
>> However, removing modesetting_drv.so from
>> /usr/lib/xorg/modules/drivers did. That solved the problem.
>
>> But it didn't switch to nouveau; it went to fbdev.
>
> You likely created a new problem. modesetting_drv.so is the default DIX for
> AMD,
> Int
John Goerzen composed on 2022-02-28 22:11 (UTC-0600):
> Interestingly, purging xserver-xorg-video-nouveau didn't change
> anything.
That means you must have been /using/ the modesetting DIX driver.
> However, removing modesetting_drv.so from
> /usr/lib/xorg/modules/drivers did. That solved the
On Mon, Feb 28 2022, Felix Miata wrote:
> There are two nouveau drivers:
>
> kernel device
> display device
> modesetting
> nouveau
>
> Both possible full-function display device drivers depend on the nouveau
> kernel
> driver (module). inxi -Gayz will show
On Mon, Feb 28, 2022, 3:43 PM John Goerzen wrote:
> Hi,
>
> I have a system with a GeForce 1050 Ti on bullseye.
>
> On this system, if I log in as a regular user and run startx, everything
> works fine; KDE Plasma comes up and it's all good.
>
> But sddm doesn't work. In fact, when it starts, it
John Goerzen composed on 2022-02-28 15:43 (UTC-0600):
> I have a system with a GeForce 1050 Ti on bullseye.
> On this system, if I log in as a regular user and run startx, everything
> works fine; KDE Plasma comes up and it's all good.
> But sddm doesn't work. In fact, when it starts, it causes
On 2014-03-25 12:08:12 +0200, Andrei POPESCU wrote:
> Alt-SysRq-F is disabled on sid:
> mar 25 12:03:28 sid kernel: SysRq : This sysrq operation is disabled.
But what if someone logs in, uses all the memory left (possibly not
even in a malicious way) so that this triggers the OOM killer, and
the O
On Vi, 21 mar 14, 10:34:03, Darac Marjal wrote:
> On Fri, Mar 21, 2014 at 11:46:38AM +0200, Andrei POPESCU wrote:
> > On Vi, 21 mar 14, 09:52:09, Gian Uberto Lauri wrote:
> > >
> > > You can access the console X was started from even when the machine is
> > > locked.
> >
> > Seriously? I'd find t
On Mon 24 Mar 2014 at 12:37:36 +0100, Vincent Lefevre wrote:
> On 2014-03-23 21:06:55 +0100, Jörg-Volker Peetz wrote:
> > Seems I'm a little bit old-fashioned ;-)
> > According to the man-page Xsession(5) the system scripts take care of using
> > a
> > log-file, given that you indeed don't have ~
On 2014-03-23 21:06:55 +0100, Jörg-Volker Peetz wrote:
> Seems I'm a little bit old-fashioned ;-)
> According to the man-page Xsession(5) the system scripts take care of using a
> log-file, given that you indeed don't have ~/.xinitrc .
> So maybe the man-page of startx(1) has to be updated, since i
Seems I'm a little bit old-fashioned ;-)
According to the man-page Xsession(5) the system scripts take care of using a
log-file, given that you indeed don't have ~/.xinitrc .
So maybe the man-page of startx(1) has to be updated, since it only talks about
~/.xinitrc .
Best regards,
Jörg-Volker.
On Sat 22 Mar 2014 at 21:19:59 +0100, Sven Joachim wrote:
> On 2014-03-22 20:14 +0100, Brian wrote:
>
> > This is the fourth or fifth time in this thread a recommendation to use
> > ~/.xinitrc has been made. No sensible Debian user would have such a file
> > in his account.
>
> Care to elaborate
On Sat 22 Mar 2014 at 15:02:58 -0500, Bill Wood wrote:
> On Sat, 2014-03-22 at 19:14 +, Brian wrote:
>. . .
> > This is the fourth or fifth time in this thread a recommendation to use
> > ~/.xinitrc has been made. No sensible Debian user would have such a file
> > in his account. A happy D
On 2014-03-22 20:14 +0100, Brian wrote:
> On Sat 22 Mar 2014 at 17:50:11 +0100, Jörg-Volker Peetz wrote:
>
>> Jörg-Volker Peetz wrote, on 03/22/2014 16:52:
>> > In order to keep the output of the X-session when starting with the command
>> > startx, something like the following snippet could be in
On Sat, 2014-03-22 at 19:14 +, Brian wrote:
. . .
> This is the fourth or fifth time in this thread a recommendation to use
> ~/.xinitrc has been made. No sensible Debian user would have such a file
> in his account. A happy Debian system is one with ~/.xsession.
I'm a Debian newbie, so --
On Sat 22 Mar 2014 at 17:50:11 +0100, Jörg-Volker Peetz wrote:
> Jörg-Volker Peetz wrote, on 03/22/2014 16:52:
> > In order to keep the output of the X-session when starting with the command
> > startx, something like the following snippet could be inserted into the file
> > ~/.xinitrc :
This is
Jörg-Volker Peetz wrote, on 03/22/2014 16:52:
> In order to keep the output of the X-session when starting with the command
> startx, something like the following snippet could be inserted into the file
> ~/.xinitrc :
>
>
> sessid="${HOSTNAME:-$(uname -n)}-${DISPLAY##*:}"
>
> # Send output to fi
In order to keep the output of the X-session when starting with the command
startx, something like the following snippet could be inserted into the file
~/.xinitrc :
sessid="${HOSTNAME:-$(uname -n)}-${DISPLAY##*:}"
# Send output to file
#
logfile="${XDG_CACHE_HOME:-$HOME}/xinit-${sessid}.log"
:
On Sat, Mar 22, 2014 at 8:51 AM, Brian wrote:
> On Fri 21 Mar 2014 at 12:37:57 -0400, Steve Litt of Troubleshooters.Com
> wrote:
>
> > I think it depends on the situation. If you're at the library with your
> > laptop and need to go to the bathroom, it's best to take the computer
> > with you, be
On 2014-03-21 13:35:37 -0400, Steve Litt of Troubleshooters.Com wrote:
> To cure my paranoia of having stdout going to an unknown place, I made
> the following executable /usr/local/bin/exx:
>
> ==
> #!/bin/bash
> startx > /dev/null & exit
> ==
>
>
On 2014-03-21 17:13:41 +0100, Gian Uberto Lauri wrote:
> Vincent Lefevre writes:
> > The fact that it is multi-user doesn't mean that it will necessarily
> > be used by several desktop users.
>
> You can remove spawning the getty on tty you don't want to use.
>
> I don't know how to do this wit
On Fri 21 Mar 2014 at 12:37:57 -0400, Steve Litt of Troubleshooters.Com wrote:
> I think it depends on the situation. If you're at the library with your
> laptop and need to go to the bathroom, it's best to take the computer
> with you, because it's easier to just walk off with it than to dink
> w
On Fri 21 Mar 2014 at 12:37:57 -0400, Steve Litt of Troubleshooters.Com wrote:
> I think it depends on the situation. If you're at the library with your
> laptop and need to go to the bathroom, it's best to take the computer
> with you, because it's easier to just walk off with it than to dink
> w
On Fri 21 Mar 2014 at 12:37:57 -0400, Steve Litt of Troubleshooters.Com wrote:
> On Fri, 21 Mar 2014 11:06:03 +
> Robin wrote:
>
> > I may have missed something. If someone has physical access to your
> > machine can't they just power off and go into single user mode and
> > change the root
On Fri, 21 Mar 2014 14:25:14 +0100
"Valerio Vanni" wrote:
> "Brian" ha scritto nel messaggio
> news:21032014113647.c62190855...@desktop.copernicus.demon.co.uk
>
> > For the situation when X is started with startx would 'startx &
> > exit' prevent the termination of an X session even if CTRL+ALT
Steve Litt of Troubleshooters.Com writes:
> I think it depends on the situation. If you're at the library with your
> laptop and need to go to the bathroom, it's best to take the computer
> with you, because it's easier to just walk off with it than to dink
> with the command prompt.
Easier a
On Fri, 21 Mar 2014 11:06:03 +
Robin wrote:
> I may have missed something. If someone has physical access to your
> machine can't they just power off and go into single user mode and
> change the root password?
Unless you have a BIOS password or encrypted root partition (or
encrypted partiti
On Fri, 21 Mar 2014 09:24:21 +
Jonathan Dowland wrote:
> On Thu, Mar 20, 2014 at 02:19:46PM +, Brian wrote:
> >Ctrl+Alt+F1...F12
> > For systems with virtual terminal support, these keystroke
> > combinations are used to switch to virtual terminals 1
> > throug
Vincent Lefevre writes:
> The fact that it is multi-user doesn't mean that it will necessarily
> be used by several desktop users.
You can remove spawning the getty on tty you don't want to use.
I don't know how to do this with systemd... With init you had some
nice and well commented entries i
On 2014-03-21 11:41:29 +, Brian wrote:
> For the situation when X is started with startx would 'startx & exit'
> prevent the termination of an X session even if CTRL+ALT+FN etc gets
> console access?
Doing the exit immediately can have some side effects in some
configurations. For instance, my
On 2014-03-21 10:34:03 +, Darac Marjal wrote:
> On Fri, Mar 21, 2014 at 11:46:38AM +0200, Andrei POPESCU wrote:
> > On Vi, 21 mar 14, 09:52:09, Gian Uberto Lauri wrote:
> > >
> > > You can access the console X was started from even when the machine is
> > > locked.
> >
> > Seriously? I'd find
On Fri 21 Mar 2014 at 14:25:14 +0100, Valerio Vanni wrote:
> "Brian" ha scritto nel messaggio
> news:21032014113647.c62190855...@desktop.copernicus.demon.co.uk
>
> > For the situation when X is started with startx would 'startx & exit'
> > prevent the termination of an X session even if CTRL+ALT
On Friday 21 March 2014 11:06:03 Robin wrote:
> If someone has physical access to your
> machine can't they just power off and go into single user mode and
> change the root password?
The default on Debian since I have been using it is that the root
password is required for access via single user
berenger.mo...@neutralite.org writes:
>
>
> Le 21.03.2014 13:54, Gian Uberto Lauri a écrit :
> > berenger.mo...@neutralite.org writes:
> > > Can't ~/.xinitrc force startx to logout?
> >
> > H, maybe if you start x with . xinitrc .
Me _idiot_! (despite the triple expresso shot).
I sh
"Brian" ha scritto nel messaggio
news:21032014113647.c62190855...@desktop.copernicus.demon.co.uk
> For the situation when X is started with startx would 'startx & exit'
> prevent the termination of an X session even if CTRL+ALT+FN etc gets
> console access?
I've always used "startx & exit", and
On 21 March 2014 11:18, Darac Marjal wrote:
> On Fri, Mar 21, 2014 at 11:06:03AM +, Robin wrote:
>> I may have missed something. If someone has physical access to your
>> machine can't they just power off and go into single user mode and
>> change the root password?
>
> Maybe, maybe not. Conso
Le 21.03.2014 13:54, Gian Uberto Lauri a écrit :
berenger.mo...@neutralite.org writes:
> Can't ~/.xinitrc force startx to logout?
H, maybe if you start x with . xinitrc . Would you forgive me if
I
don't do the test right now and continue to do the work I am paid for
:) ?
Currently, yo
berenger.mo...@neutralite.org writes:
> Can't ~/.xinitrc force startx to logout?
H, maybe if you start x with . xinitrc . Would you forgive me if I
don't do the test right now and continue to do the work I am paid for
:) ?
--
/\ ___Ubuntu: anci
Le 20.03.2014 02:44, Zenaan Harkness a écrit :
Yeah, when making a machine for a less technical or less
command-prompt
comfortable person, I like to have it boot into GUI via the desktop
manager. But when setting it up for myself or for people technically
sharp enough to log in and then type "
On Fri 21 Mar 2014 at 11:18:19 +, Darac Marjal wrote:
> On Fri, Mar 21, 2014 at 11:06:03AM +, Robin wrote:
> > I may have missed something. If someone has physical access to your
> > machine can't they just power off and go into single user mode and
> > change the root password?
>
> Maybe
On Fri, Mar 21, 2014 at 11:06:03AM +, Robin wrote:
> I may have missed something. If someone has physical access to your
> machine can't they just power off and go into single user mode and
> change the root password?
Maybe, maybe not. Console access doesn't have to mean complete access.
The s
I may have missed something. If someone has physical access to your
machine can't they just power off and go into single user mode and
change the root password?
--
rob
--
To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...
On Fri 21 Mar 2014 at 10:24:54 +, Jonathan Dowland wrote:
> On Fri, Mar 21, 2014 at 09:52:03AM +, Brian wrote:
> > In an xterm (with or without using DontVTSwitch):
> >
> >brian@localhost:~$ chvt 4
> >Couldn't gat a file descriptor referring to the console
> >
> > Doubt no longer
On Fri, Mar 21, 2014 at 11:46:38AM +0200, Andrei POPESCU wrote:
> On Vi, 21 mar 14, 09:52:09, Gian Uberto Lauri wrote:
> >
> > You can access the console X was started from even when the machine is
> > locked.
>
> Seriously? I'd find that to be a severe bug in the said locking
> application.
It
On Fri, Mar 21, 2014 at 09:52:03AM +, Brian wrote:
> In an xterm (with or without using DontVTSwitch):
>
>brian@localhost:~$ chvt 4
>Couldn't gat a file descriptor referring to the console
>
> Doubt no longer. :)
Try via sudo. (risk reduced to: X session left open, terminal left open
On Fri 21 Mar 2014 at 09:24:21 +, Jonathan Dowland wrote:
> On Thu, Mar 20, 2014 at 02:19:46PM +, Brian wrote:
> >Ctrl+Alt+F1...F12
> > For systems with virtual terminal support, these keystroke
> > combinations are used to switch to virtual terminals 1
> > thro
On Vi, 21 mar 14, 09:52:09, Gian Uberto Lauri wrote:
>
> You can access the console X was started from even when the machine is
> locked.
Seriously? I'd find that to be a severe bug in the said locking
application.
Kind regards,
Andrei
--
http://wiki.debian.org/FAQsFromDebianUser
Offtopic disc
On Thu, Mar 20, 2014 at 02:19:46PM +, Brian wrote:
>Ctrl+Alt+F1...F12
> For systems with virtual terminal support, these keystroke
> combinations are used to switch to virtual terminals 1
> through 12, respectively. This can be disabled with the
> DontVTSwitc
Andrei POPESCU writes:
> 3. any user, with or without root access, who doesn't lock his
> workstation as needed[1] deserves his fate.
And does not uses startx; exit
You can access the console X was started from even when the machine is
locked.
--
/\ ___
On Jo, 20 mar 14, 12:44:21, Zenaan Harkness wrote:
>
> Anyone with physical access to your computer could:
>
> a) logout of your gui session (if it's not screensaver locked), taking
> them back to your command line, and depending on your settings of
> /etc/sudoers tty_tickets or respectively !tty
On Wed 19 Mar 2014 at 22:48:49 -0400, Steve Litt of Troubleshooters.Com wrote:
> On Thu, 20 Mar 2014 12:44:21 +1100
> Zenaan Harkness wrote:
>
> > SO: what to do?
> >
> > What I did for a while was:
> > a) log in to Linux console
> > b) startx; exit
>
> Outstanding! I'm going to start doing th
On Thu 20 Mar 2014 at 12:44:21 +1100, Zenaan Harkness wrote:
> > Yeah, when making a machine for a less technical or less command-prompt
> > comfortable person, I like to have it boot into GUI via the desktop
> > manager. But when setting it up for myself or for people technically
> > sharp enough
On 2014-03-20, Vincent Lefevre wrote:
>
> For instance, type:
>
> sleep 2; exit
>
> and Ctrl-C just after. The "sleep 2" is interrupted, but "exit"
> isn't run.
>
> You could still do "exec startx", but this may not be OK if you
> want *logout files to be sourced for clean-up.
Not using sudo wo
On 2014-03-20 12:44:21 +1100, Zenaan Harkness wrote:
> When logging in at the Linux console (on current kernels at least),
> then running startx, there is a security problem:
>
> Anyone with physical access to your computer could:
>
> a) logout of your gui session (if it's not screensaver locked)
On 20/03/14 13:48, Steve Litt of Troubleshooters.Com wrote:
> On Thu, 20 Mar 2014 12:44:21 +1100
> Zenaan Harkness wrote:
>
>>> Yeah, when making a machine for a less technical or less
>>> command-prompt comfortable person, I like to have it boot into GUI
>>> via the desktop manager. But when set
>> their way with the machine.
>
> Of course. This is simply one extra layer of protection, and will only
> protect you against a quick-and-dirty type attach which might
> otherwise be done in just a few seconds. This script can prevent that
> type of physical-access attack,
On 3/20/14, Steve Litt of Troubleshooters.Com wrote:
> On Thu, 20 Mar 2014 12:44:21 +1100
> Zenaan Harkness wrote:
>
>> > Yeah, when making a machine for a less technical or less
>> > command-prompt comfortable person, I like to have it boot into GUI
>> > via the desktop manager. But when setting
On Thu, 20 Mar 2014 12:44:21 +1100
Zenaan Harkness wrote:
> > Yeah, when making a machine for a less technical or less
> > command-prompt comfortable person, I like to have it boot into GUI
> > via the desktop manager. But when setting it up for myself or for
> > people technically sharp enough t
> Yeah, when making a machine for a less technical or less command-prompt
> comfortable person, I like to have it boot into GUI via the desktop
> manager. But when setting it up for myself or for people technically
> sharp enough to log in and then type "startx" (and people you can
> trust with the
On Wednesday 19 March 2014 15:50:41 Steve Litt of Troubleshooters.Com
wrote:
> And last but
> not least, booting to CLI and using startx gives me that nostalgic
> feeling for when I was a young whippersnapper using Red Hat 5.1.
:-)
Lisi
--
To UNSUBSCRIBE, email to debian-user-requ...@lists.de
On 1/3/14, Brian wrote:
> On Fri 03 Jan 2014 at 16:28:05 +1100, Zenaan Harkness wrote:
>> On 12/13/13, Zenaan Harkness wrote:
>> >
>> > Clearly consolekit is started (logout, as well as reboot etc now
>> > work), my keyboard shortcuts work etc.
>> >
>> > This seems ideal - no per-user configurati
On Fri 03 Jan 2014 at 16:28:05 +1100, Zenaan Harkness wrote:
> On 12/13/13, Zenaan Harkness wrote:
> >
> > Clearly consolekit is started (logout, as well as reboot etc now
> > work), my keyboard shortcuts work etc.
> >
> > This seems ideal - no per-user configuration, and it just works (TM)(C)(R)
On 12/13/13, Zenaan Harkness wrote:
> On 12/13/13, Brian wrote:
>> On Thu 12 Dec 2013 at 17:23:31 +1100, Zenaan Harkness wrote:
>>
>>> What seemed like a good idea, at, the, time ... is longer looking so
>>> good. Any ideas why this odd behaviour would appear as it does?
>>
>> You could try follo
On 2013-12-12 00:21:18 -0700, Bob Proulx wrote:
> 2.1 xdm graphical login manager (or gdm, or kdm, or lightdm, or other)
> Runs /etc/X11/Xsession
> Redirects output to .xsession-errors
[...]
Not for gdm3 3.5.2+. $XDG_CACHE_HOME/gdm/session.log is now used,
but this is currently a bi
On Mon 16 Dec 2013 at 11:32:02 +1100, Zenaan Harkness wrote:
> On 12/16/13, Brian wrote:
> >
> > I gave kdm a quick whirl with Xfce on Wheezy. No problem (I only tested
> > ALT-F2), but no advice for you either.
>
> It seems that, for me, a shortcut involving the "Windows Logo" key
> does not wo
On Mon 16 Dec 2013 at 17:17:01 +1300, Chris Bannister wrote:
> On Sat, Dec 14, 2013 at 08:25:56PM +, Brian wrote:
> >
> > Put
> >
> >exec fvwm
> >
> > after the xterm command in .xsession. This command does not complete and
> > .xsession doesn't close. You've summoned X, give it a chanc
On Sat, Dec 14, 2013 at 08:25:56PM +, Brian wrote:
>
> Put
>
>exec fvwm
>
> after the xterm command in .xsession. This command does not complete and
> .xsession doesn't close. You've summoned X, give it a chance to show off
> what it can do :).
>
> EXERCISE: You decide 'exec fvwm' is a
On 12/16/13, Brian wrote:
> On Sun 15 Dec 2013 at 11:27:26 +1100, Zenaan Harkness wrote:
>
>> On 12/13/13, Zenaan Harkness wrote:
>> > So I have no per-user config, such as ~/.xinitrc , ~/.xsession and
>> > ~/.xsessionrc .
>> >
>> > startx after linux console login works well.
>>
>> That is, to s
On Sun 15 Dec 2013 at 11:27:26 +1100, Zenaan Harkness wrote:
> On 12/13/13, Zenaan Harkness wrote:
> > So I have no per-user config, such as ~/.xinitrc , ~/.xsession and
> > ~/.xsessionrc .
> >
> > startx after linux console login works well.
>
> That is, to start xfce
>
> > When I login to Lin
On 12/13/13, Zenaan Harkness wrote:
> So I have no per-user config, such as ~/.xinitrc , ~/.xsession and
> ~/.xsessionrc .
>
> startx after linux console login works well.
That is, to start xfce
> When I login to Linux console, then run
> sudo service kdm start, and then login from there to xfce
On Sun 15 Dec 2013 at 06:29:52 +1300, Chris Bannister wrote:
> JFTR, I am running FVWM and have the following:
> tal% less .xsessionrc
> /home/chrisb/background.sh &
>
> xterm -fn 10x20 -xrm "XTerm.vt100.background: #CCA8AA" -xrm \
> "XTerm.vt100.foreground: blue" -geom 120x15 &
> tal%
You sta
On Sun, 15 Dec 2013 06:29:52 +1300 Chris Bannister sent:
> I do remember this issue in the past, a google was not very helpful -
> and may even have been misleading - e.g. suggesting that .xsessionrc
> was the correct file to use. And since .xsession or .xinitrc didn't
> work I must have assumed
On Thu, Dec 12, 2013 at 02:23:48PM +, Brian wrote:
> On Thu 12 Dec 2013 at 00:21:18 -0700, Bob Proulx wrote:
>
> > The man page for Xsession documents ~/.xsessionrc and ~/.xsession. It
> > says that ~/.xsessionrc is only for setting variables and the
> > ~/.xsession is for executing commands.
Brian wrote:
> May we look a little closer at one or two of the things you say?
>
> Bob Proulx wrote:
> > Because startx does not use .xsession. You have things criss-crossed.
Oops! I was definitely wrong with that statement.
> 1. Running startx basically runs xinit.
>
> 2. startx first looks
On 12/13/13, Brian wrote:
> On Thu 12 Dec 2013 at 17:23:31 +1100, Zenaan Harkness wrote:
>
>> What seemed like a good idea, at, the, time ... is longer looking so
>> good. Any ideas why this odd behaviour would appear as it does?
>
> You could try following the advice given in
>
>/usr/share/do
On Thu, 12 Dec 2013 19:13:50 + Brian sent:
> [When talking about .xsessionrc versus .xsession]
>
> > I might just revert it back to ~/.xsession and see what error
> > messages I receive, if any?
>
> You won't get any error messages. The system will execute valid
> commands in .xessionrc ju
On Thu, 12 Dec 2013 14:23:48 + Brian sent:
> Putting commands in .xsessionrc is very naughty. Are you still there,
> Charlie? For your own good, please stop doing it.
I've renamed the file to ~/.xsession after reading the information Bob
kindly supplied and it's all working great, as normal.
On Thu 12 Dec 2013 at 17:47:12 +1100, Charlie wrote:
> I'm happy with what happens when I boot my system - same as when I
> used .xsessionrc with FVWM. But will look into it and read a bit when
> time permits. I could be doing the wrong thing entirely.
You are. But you will never know until you e
On Thu 12 Dec 2013 at 22:18:31 +1100, Charlie wrote:
[When talking about .xsessionrc versus .xsession]
> I might just revert it back to ~/.xsession and see what error messages
> I receive, if any?
You won't get any error messages. The system will execute valid commands
in .xessionrc just as well
On Thu 12 Dec 2013 at 19:06:41 +1100, Zenaan Harkness wrote:
> I have been trying to get a setup that works properly with startx, as
> well as with kdm. Do you have a recommendation as to how best to
Your original query concerned startx only. You have now escalated the
problem to include kdm :).
May we look a little closer at one or two of the things you say?
On Wed 11 Dec 2013 at 23:36:51 -0700, Bob Proulx wrote:
> Because startx does not use .xsession. You have things criss-crossed.
1. Running startx basically runs xinit.
2. startx first looks for ~/.xinitrc which, unless there is a
1 - 100 of 341 matches
Mail list logo
