Created attachment 482373 [details] dmesg output with kernel mode setting active Description of problem: System is set to start in multi-user mode (text, run level 3) When a system is started with kernel mode switching available and the console switches from the normal vga console to a framebuffer console, systemd refuses to start a getty (agetty) on the console, thus preventing login. Version-Release number of selected component (if applicable): kernel-2.6.38-0.rc6.git6.1.fc15.i686 systemd-19-1.fc15.i686 util-linux-2.19-3.fc15.i686 How reproducible: Set system to start in multi-user mode (non-graphical) by creating a symlink /etc/systemd/system/default.target pointing to /lib/systemd/system/runlevel3.target Steps to Reproduce: 1. Boot system Actual results: System comes up all the way except for login prompt. Expected results: System comes up all the way and then allows login at prompt. Additional info: The failure occurs with Kernel Mode Setting active. If the Kernel Mode Setting is disabled with the command line option "nomodeset" then the agetty is started as expected and normal login can occur. System is a Gateway 450ROG laptop with an ATI Mobility 9 (R250) video chip with dedicated 64MB RAM. The attached files are dmesg output with Kernel Mode Setting (dmesg.kms), dmesg without mode setting (dmesg.nomodeset) and the last few lines of the console output without mode setting (console-nomodeset.txt) For the dmesg files I activated the debug output of systemd by editing the /etc/systemd/system.conf file and set LogLevel=debug.
Created attachment 482374 [details] dmesg output with kernel mode setting disabled (nomodeset)
Created attachment 482375 [details] last bit of console output without kernel mode setting
My guess is that plymouth is frozen and the gettys wait for that. And if you disable KMS then Plymouth will run in a different mode. Do the gettys appear if you wait a couple of minutes?
Your guess is correct. The getty's never appear because they are waiting on plymouth, and they will wait forever (> 1hour) because plymouth never exits: [gus@rawhide ~]$ ps -efw|grep plymouth root 914 1 0 17:08 ? 00:00:00 /bin/plymouth --wait I was able to check this by ssh'ing into the machine. I then kill the plymouth process: $ sudo kill 914 And I get my login prompt on the console. I would really like to get rid of plymouth but it seems so ingrained into everything that I can't remove it without breaking a bunch of packages. I don't know why there is such a paranoid Fear Of Text (TM) that requires plymouth to cover it up, but I guess that's another bug report ;)
Looks like this was fixed in the latest release of plymouth. I did an update and all was working: plymouth-graphics-libs-0.8.4-0.20110304.1.fc15.i686 plymouth-scripts-0.8.4-0.20110304.1.fc15.i686 plymouth-core-libs-0.8.4-0.20110304.1.fc15.i686 plymouth-plugin-label-0.8.4-0.20110304.1.fc15.i686 plymouth-theme-charge-0.8.4-0.20110304.1.fc15.i686 plymouth-plugin-two-step-0.8.4-0.20110304.1.fc15.i686 plymouth-system-theme-0.8.4-0.20110304.1.fc15.i686 plymouth-0.8.4-0.20110304.1.fc15.i686 Now if only I can fix the damn framebuffer font size.
*** This bug has been marked as a duplicate of bug 679503 ***