Sign up ×
Ask Ubuntu is a question and answer site for Ubuntu users and developers. It's 100% free.

I'm running a stripped down (minimal install version) of Lucid.

For some reason, xinit seems to be failing on boot and I'm not sure what logs I should start checking - normally I would go with the Xorg ones in /var/logs, but running xinit manually after login works just fine, and as far as I can tell the usual Xorg.#.# files aren't created.

Can anyone give me any suggestions as to where to start looking?

share|improve this question

closed as too localized by Bruno Pereira, Marco Ceppi Feb 2 '12 at 17:52

This question is unlikely to help any future visitors; it is only relevant to a small geographic area, a specific moment in time, or an extraordinarily narrow situation that is not generally applicable to the worldwide audience of the internet. For help making this question more broadly applicable, visit the help center.If this question can be reworded to fit the rules in the help center, please edit the question.

This question seems abandoned, there is not further information or activity added to it for several months. I am flagging this to be closed by a moderator. If you think this issue is still affecting you you can flag a moderator to re-open it. – Bruno Pereira Feb 2 '12 at 17:20

4 Answers 4

It is difficult to answer this question without knowing how xinit is invoked. This script in place of xinit could help you get a handle on what is failing:

# xinit-debug: try to start x with info to /var/log/syslog
# requires the ubuntu "bsdutils" package for "logger(1)"
# and "coreutils" for "id(1)"

tag="-t xinit-debug"
logger $tag `id`
logger $tag about to xinit
xinit 2> /tmp/xlog.$$
logger $tag xinit exited with status $?
logger $tag /tmp/xlog.$$: `head /tmp/xlog.$$`
share|improve this answer
How is xinit usually invoked? Presumably it comes in through an init.d script, but a quick glance through those directories didn't turn anything likely up. – javanix Oct 27 '10 at 18:56
In a default Ubuntu installation, the X server is started by gdm which in turn is started by upstart (a.k.a "the new init"). The relevant configuration file lives in /etc/init/gdm.conf. init.d is a historical legacy which is slowly being migrated away from. – msw Oct 28 '10 at 4:32

I have the following script in /etc/init, it is used for starting xbmc:

description     "XBMC"
author          "Michel Wilson"

start on (filesystem and stopped udevtrigger)

stop on runlevel [06]


exec /bin/su xbmc -l -c "/bin/bash --login -c startx > /dev/null 2>&1"

The startx command uses .xinitrc in the home directory of the user it is running under. In this case, I simply start xbmc, no window manager is needed. Note that the user you use to run startx might need to be a member of certain groups for this to work. I believe at least the video group is needed for X to work, but I'm not sure.

share|improve this answer

I find it best to run startx from user login's bash_profile:;a=blob;f=.bash_profile;h=0adfcc8d3f9dbc8579c2b7a48a3abf1a301fa9c3;hb=HEAD#l29

init.d is sucky otherwise.

share|improve this answer

I have a similar setup, and usually end up with quite a lot of output on my TTY1 (if you press Ctrl+Alt+F1 - pressing Ctrl+Alt+F7 should get you back to X). This only happened while I was using Getty as a login manager, which is set by default after a minimal install.

If you use another login manager, like GDM or SLiM, it might be worth checking into their logs (if they create any).

share|improve this answer

Not the answer you're looking for? Browse other questions tagged or ask your own question.