Description of problem: When booting, everything looks as normal, but suddenly the display is switched to the console instead of X. A Ctrl+Alt+F7 gets you back to the login screen, but it is a bit annoying. I use the following config: /etc/sysconfig/desktop ====================== DESKTOP="KDE" DISPLAYMANAGER="KDE" I have no idea if it's kdm that does something strange, or if it is something else. X doesn't get shut down or anything. I've also tried activating automatic login via KDE, and when I switch to X from console, I see that it has indeed logged me on, and started KDE and everything. Version-Release number of selected component (if applicable): Default FC6. How reproducible: Every time (? - or very often) Steps to Reproduce: 1. Reboot the computer 2. Watch the screen 3. Actual results: If someone sits down in front of the computer after a boot, he/she is presented with a non-graphic, text-only, console login. Expected results: If someone sits down in front of the computer after a boot, he/she is presented with a graphic, very nice-looking X (Fedora) login. Additional info: If someone doesn't know that Ctrl+Alt+F7 exists, they might get very confused.
This happens after the graphical boot display. Everything seems as usual there. So it's after all those "Starting networking", and similar messages, when the X server restarts (?) for the login / desktop screen. So, X is displayed until that point, then it switches to the first console screen (Ctrl+Alt+F1).
I just tried changing back to gdm, with no autologon. After a few boots the same thing happened. It switched to console login instead of the GDM login screen, just when that login screen was loading. Alt+F7, and you get the GDM login instead....
Does not matter if you use GDM or KDM. A friend has the same problem. Both of us use the Nvidia drivers. Can this make a difference? It didn't in FC5. It's possible to do a workaround by removing rhgb from /etc/grub/grub.conf, but you won't get a graphical boot either. But it seems to work better.
Thanks for the bug report. We have reviewed the information you have provided above, and there is some additional information we require that will be helpful in our diagnosis of this issue. Please attach your X server config file (/etc/X11/xorg.conf) and X server log file (/var/log/Xorg.*.log) to the bug report as individual uncompressed file attachments using the bugzilla file attachment link below. We will review this issue again once you've had a chance to attach this information. Thanks in advance.
Created attachment 141656 [details] xorg.conf
Created attachment 141657 [details] Xorg.0.log
Created attachment 141658 [details] Xorg.1.log
Could you please try to reproduce this bug with nv driver? We are not providing support of nvidia binary-only drivers, as we don't have access to the source code as well, so I would have to close your bug as invalid if you cannot reproduce it with nv.
I'll see if I get the time to do that. I'm a bit busy right now, and it's something that will take some time to test. If it gets through five boots, is it ok? It might fail on the sixth.. So I will have to do lots of reboots to test that, and I can't do it right now. By the way.. Maybe too early to say, but it seems like it has worked quite well the last few days. But I haven't upgraded anything. Only thing I did was remove the webcamera, but that can't have anything to do with this, can it?
The problem seems to have gone away after I applied a whole bunch of updates a couple of weeks ago. I can not say which update it was, as I installed all available updates. Among them the kernel, X and the nvidia drivers. It might have been any of those. I didn't have time to use the nv driver long enough to know if it made any difference or not. I guess you can close the bug now. :-)