You are not logged in.
After the recent upgrade to gnome 2.28, I tried changing the way I start gdm. According to the Arch Wiki the recommended way is to start gdm from /etc/inittab using:
...
id:5:initdefault:
...
x:5:respawn:/usr/sbin/gdm -nodaemon
It was unsuccessful. I got a few of these error messages:
gdm-binary: ... WARNING ...Couldn't connect to system bus ...Failed to connect to socket /var/run/dbus/system_bus_socket : No such file or directory..
followed by the message:
INIT: Id "x" spawning too fast ... waiting for 5 minutes.
Then after 5 minutes it starts gdm and everything is fine.
Can anyone help me resolve the issue? I had so far been starting gdm using the DAEMONS list in /etc/rc.conf. But after the recent upgrade, once in a while I am left at the console login prompt and gdm does not start. This is why I thought of switching over to the inittab way of starting gdm. But apparently that turned out to be even worse. By the way i do have hal in my DAEMONS list and so dbus does get started but apparently not fast enough for gdm( I guess ).
Offline
Apparently dbus is not ready when init tries to execute this inittab line. How do you start dbus/hal?
Last edited by bernarcher (2009-10-18 12:57:11)
To know or not to know ...
... the questions remain forever.
Offline
hal is started from the DAEMONS list in /etc/rc.conf. I have mentioned this. How do I start dbus/hal before that line is executed in inittab?
Offline
Could you post your DAEMONS line, please.
To know or not to know ...
... the questions remain forever.
Offline
Thanks for trying to help.
DAEMONS=(syslog-ng hal !network !netfs @crond @alsa @cpufreq )
This is the one I used when i used inittab to start gdm.
Offline
The DAEMONS look ok so far, thanks. It's all guessing, then.
Well asking the obvious first, are there any hints from the logs? dmesg? Same, if you put GDM back into DAEMONS. Something does not start properly in the init sequence, thus the timeout which in turn did force you to the console.
You could as well try to remove items one by one from the DAEMONS list. Perhaps this way the culprit will be detected.
To know or not to know ...
... the questions remain forever.
Offline
Yeah there are other issues when spawing GDM from your daemons list too...
believe it or not.. rc.local is starting to look pretty good for gdm.
But I would say the issues you have found are also pointing out what is causing the GDM spawning on TTY2 issue.
Not that I know what that is.
Offline
Any other suggestion to this problem?
Offline
With the new gdm, the inittab method of starting gdm seems to be working again.
Offline