----- Original Message -----
From: "Per Jessen"
What he's saying basically is that the xdm rc script is running before the console gettys get run, and that it's blocking the rest of the startup process until it finisheds, but it never finishes, and so init never reaches the point where it would start the console gettys.
I can't quite follow your explanation, but it sounds plausible. If this behaviour is new with 11.0, it needs to be fixed - http://bugzilla.novell.com
1) power on, kernel runs init 2) init starts reading inittab from the top # init has not yet reached any line in inittab that would launch any getty anywhere. # so, at this point there are no login prompts anywhere. 3) init encounters a line that says "run 'rc 5' and wait for it to finish before proceeding further". 4) rc starts running the various scripts in rc5.d # none of the rc5.d scripts have launched any gettys, # so still no login prompts on any ttys. ## some rc5.d scripts may have started network daemons by now, ## which may provide a login prompt via network (sshd, telnetd), ## but as it happens, xdm comes fairly early in the list. ## In any event, ssh and telnetd do not provide the login prompt on hardware tty's ## such as serial or the console, only getty does that) 5) rc reaches the xdm script and sticks there because X config is borked There is no 6) or further 6) so, rc never returns to init 7) so, init never proceeds any further in inittab 8) so, init never reaches the lines further down in inittab that would have run getty on the console tty's 9) without getty there is no login prompt. The behaviour doesn't appear to be new, as older versions of OS also had the wait action flag in the rc 5 inittab line, and that line came before the console gettys just as in 11.0 The major remaining possible difference is the xdm rc script itself or the subsequent X-related scripts. Maybe in old versions it launches Xorg with "Xorg ... &" so that the script doesn't hang even if X itself does, and maybe the new version takes away the "&" This part is conjecture but my guess is it's more likely that 11.0 behaves the same way it always did and merely his X config happens to be broken under 11.0 and not under 10.3. IE: if you have an X server that hangs under 10.3, then the entire init/rc process probably also hangs exactly as it does under 11.0, He's just lucky in that his X happens to be functional under 10.3 , not that 10.3 necessarily behaves any different. Most people never see a problem here probably because mostly when X is broken it fails in some other way than hanging. So, maybe it works or maybe it exits with an error, or maybe it crashes, but in all those cases the rc script either proceeds or crashes but does not hang, and so usually the init/rc process reaches the point of starting the console gettys. It's probably simply not all that common for it to fail in such a way that it hangs instead of aborting. It's yet another reason not to install X on a server, or at least don't use default runlevel 5 on a server. If "startx/startkde/startxfce4/etc... hangs, no one cares, the server is already all up & running and all init/rc stuff in long been completed by then. -- Brian K. White brian@aljex.com http://www.myspace.com/KEYofR +++++[>+++[>+++++>+++++++<<-]<-]>>+.>.+++++.+++++++.-.[>+<---]>++. filePro BBx Linux SCO FreeBSD #callahans Satriani Filk! -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org For additional commands, e-mail: opensuse+help@opensuse.org