It's not a real problem, more of an annoyance I want to get rid of.
Every time my system starts, gdm gets started normally, but instead of keeping tty 7 active (where GDM/X is running), I get dropped back to tty1 and have to switch back to 7 manually (ctrl + alt + F7).
So what do I need to do to just boot into the graphical server and stay there?
TIA for any help
That young girl is one of the least benightedly unintelligent organic life forms it has been my profound lack of pleasure not to be able to avoid meeting.
-- Marvin
Morimando wrote:It's not a real problem, more of an annoyance I want to get rid of.
Every time my system starts, gdm gets started normally, but instead of keeping tty 7 active (where GDM/X is running), I get dropped back to tty1 and have to switch back to 7 manually (ctrl + alt + F7).
So what do I need to do to just boot into the graphical server and stay there?
TIA for any help
I used to have this issue - figure out a way to push xdm farther down in the boot order... consider using init dependencies... add "need <whatever happens last or so>" to the depend() area of /etc/init.d/xdm
poly-p man
iVBORw0KGgoAAAANSUhEUgAAA
avatar: new version of logo - see [topic]838248[/topic]. Potentially still a WiP.
First full update of the system this year, and now X/Gnome appears to die on startup.
Added 'consolekit' to 'default' run level as recommended in other threads, but since 'xdm' uses 'consolekit', I assume that this would be started anyway.
Symptoms:
Following boot, the X/Gnome login screen appears and then vanishes, and I am left with a command line.
Login as root, I try to start 'gdm' by hand (boil down what 'xdm' is doing):
However it is still running (checked with ps), so I '--stop' the running 'gdm' and restart it.
Now the X/Gnome login screen appears and stays, and I can log in as a normal user. Not very convenient.
This does suggest that it is something to do with process start-up ordering -- but what else is 'xdm' dependent on? The processes started directly by the 'default' run level in my case are, including the just-added 'consolekit':
So... after some days uptime, i finally decided to reboot and test today.. and unfortunately the depends-idea doesn't work :/
instead of gdm getting moved down the list to bottom (as planned), the services gdm now "depends" on are move up the list..
So...still same old problem ... :/
That young girl is one of the least benightedly unintelligent organic life forms it has been my profound lack of pleasure not to be able to avoid meeting.
-- Marvin
Another possibility is that, if init processes are started as 'daemon' user, this user is now lacking some group membership. Once I log in to console mode, starting '/etc/init.d/xdm' as root does work.
Well it must be some activity on the console that makes the focus change from console 7 to console 1. At first i thought there was an issue with errors occuring on startup, but there are none any more.. at least as far as i can see. Staring gdm/xdm as root from the console works, which is only to be expected, as no more activity is going on on console 1... right?
That young girl is one of the least benightedly unintelligent organic life forms it has been my profound lack of pleasure not to be able to avoid meeting.
-- Marvin
From another thread on a very similar problem. I'll try this tonight, see if it helps.
j79zlr wrote:
sawatts wrote:ditto, except Gnome/gdm as the display manager.
Things were working fine, and have for several years on my Gentoo box. Then last weekend I updated the system, first time this year (an unusual delay as I normally update weekly) -- the usual; sync, emerge, etc-update, revdep, rinse&repeat.
I had to reinstate Gnome/gdm as my session of choice (some update doesn't preserve the selection).
But now on boot 'xdm' (in the default run level) starts long enough to show a flash of the Gnome login screen, then dies (either back to console, or if I'm unlucky, a blank screen -- I think the latter is a separate Nvidia issue).
If I remove 'xdm' from the default run level, I can log in and start the service by hand.
(* actually I'll check this later, last night I ran the 'start-stop-daemon' command directly).
I suspect (and has been suggested elsewhere here) that some service dependency isn't being reflected in the 'xdm' script. So 'xdm' starting as part of the default runlevel starts before some other service it depends upon, while starting by hand later is okay. But *what* other process is now required? It must be one started as a result of the other default entries...
(There is another thread on the same/similar problem which I have posted to as well)
Try reemerging gnome-session, there was a collision with gdm / gnome-session and installing the session file.
Update: Nope. Re-emerging gnome-session did not work.
Last edited by sawatts on Tue Apr 01, 2008 5:15 pm, edited 1 time in total.
That won't work. I have had the problem for quite a while now, meanwhile i remerged the whole system because of a broken library i was unable to find, all ~900 packets recompiled, computer busy for about 16-18hrs, everything fresh and nice, yet gdm still has the same issue...
edit: and I mean emerge --emptytree system && emerge --emptytree world, so really EVERY package was rebuilt. This has to be a configuration issue.
That young girl is one of the least benightedly unintelligent organic life forms it has been my profound lack of pleasure not to be able to avoid meeting.
-- Marvin
