X11 Xserver startup problem on a Raspberry PI

Robert Heller heller at deepsoft.com
Tue Jun 27 11:07:40 UTC 2017


At Tue, 27 Jun 2017 09:22:37 +0200 wharms at bfs.de wrote:

> 
> 
> 
> Am 27.06.2017 03:03, schrieb Robert Heller:
> > At  Robert Heller <heller at deepsoft.com> wrote:
> > 
> >>
> >> At  Robert Heller <heller at deepsoft.com> wrote:
> >>
> >>>
> >>> At Tue, 27 Jun 2017 08:55:35 +1000 Peter Hutterer <peter.hutterer at who-t.net> wrote:
> >>>
> >>>>
> >>>> On Sun, Jun 25, 2017 at 09:20:32AM -0400, Robert Heller wrote:
> >>>>> I have a Raspberry Pi (Model 2 B) running a fairly recent version of Raspbian 
> >>>>> (2017-04-10-raspbian-jessie.zip).  I have it start up to the console login, 
> >>>>> since most of the time I just ssh into it from another machine (either my 
> >>>>> CentOS laptop or desktop).  I just tied to login into its console (using my TV 
> >>>>> as a monitor) and using the startx command t fire up the GUI, but it is 
> >>>>> failing.  I *think* it is having some sort of problem with the input device I 
> >>>>> am using: a combo keyboard / trackball:
> >>>>
> >>>> there are no error messages in the log regarding libinput, it all comes up
> >>>> normally. So whatever the issue is, I don't think that's it. the logind
> >>>> messages looked fine too, so that shouldn't be an issue either.
> >>>>
> >>>> fwiw, you could easily verify it with sudo libinput-debug-events, if that
> >>>> handles the events correctly then the driver will too and you can mostly
> >>>> rule out libinput issues.
> >>>
> >>> Well, libinput-debug-events does not seem to be installed...  What package 
> >>> would it be in?  dpkg-query -l \*libinput\* yields:
> >>>
> >>> Desired=Unknown/Install/Remove/Purge/Hold
> >>> | Status=Not/Inst/Conf-files/Unpacked/halF-conf/Half-inst/trig-aWait/Trig-pend
> >>> |/ Err?=(none)/Reinst-required (Status,Err: uppercase=bad)
> >>> ||/ Name                        Version      Architecture Description
> >>> +++-===========================-============-============-===================================================================
> >>> ii  libinput-bin                1.5.0-1      armhf        input device management and event handling library - udev quirks
> >>> ii  libinput10:armhf            1.5.0-1      armhf        input device management and event handling library - shared library
> >>> ii  xserver-xorg-input-libinput 0.20.0-1     armhf        X.Org X server -- libinput input driver
> >>>
> >>>>
> >>>> "it is failing" is a bit generic, what exactly doesn't work?
> >>>
> >>> The XServer does not start -- I type startx, and after a brief startup blather
> >>> and a brief screen blanking, it lands back at the shell prompt. The log file
> >>> is all I have. Yes, it appears that XServer sees everything, but for some
> >>> reason just exits after it has finished probing... No "obvious" (to me) reason
> >>> (I have seen Xservers die for various reasons, like bad video timing rates on
> >>> unsupported video chips, or totally missing mice and/or keyboards -- mostly in
> >>> the "bad old days" where one had to set things up properly in
> >>> /etc/X11/xorg.conf. I believe these days, one does not bother with
> >>> hand-crafter conf files -- the XServer figures itself out "on the fly". (Or
> >>> not as the case might be...)
> >>
> >> OK, another datapoint:
> >>
> >> *I* don't use the "pi" account on my pis -- I create an account "heller" so 
> >> make things consistent with my other Linux boxes (an x86_64 home built desktop 
> >> and a x86_64 Lenovo Thinkpad laptop).
> >>
> >> When I log into the 'Pi as "pi", startx works.  It does not work when I log in 
> >> as heller.  This is *weird* (at least from this long time Linux user).
> >>
> > 
> > OK, problem solved: it was a bad .xsession file.  It has been so long since I 
> > needed to troubleshoot a .xsession that I had forgotten to check there.  
> >
> 
> could you elaborate that a bit ?
> When a .xsession causes "could not write pid to lock file in /tmp/.tX1-lock"
> Then it sounds not very helpful, may be that can be changed.


*I* was not having problems with the lock file. My .xsession file was trying
to run a program that was not installed. It was left over from an earlier
version of Raspbian. In the previous version I had installed pieces of Gnome
(specificly gnome-panel), that were not installed when I upgraded the system
(I had backed up /home and restored it after regenerating the micro sd card).  
There was also random cruft under ~/.config that was not working properly.  I 
am now in the process of "re-creating" my desktop environment, while includes 
changing the window manager, removing the GUI file manager (which I don't 
use), etc.

> 
> re,
>  wh
> 
> 
> 
> _______________________________________________
> xorg at lists.x.org: X.Org support
> Archives: http://lists.freedesktop.org/archives/xorg
> Info: https://lists.x.org/mailman/listinfo/xorg
> Your subscription address: %(user_address)s
> 
>                                                                                                          

-- 
Robert Heller             -- 978-544-6933
Deepwoods Software        -- Custom Software Services
http://www.deepsoft.com/  -- Linux Administration Services
heller at deepsoft.com       -- Webhosting Services
                       


More information about the xorg mailing list