This bug splits off the problem described in comments #12 through #20 of https://bugzilla.redhat.com/show_bug.cgi?id=848305 . After plymouth was updated to 0.8.7 - partly to fix that bug - a serious issue showed up with several NVIDIA adapters: when booting normally to a desktop, runlevel '5', plymouth enabled, all as normal, either the DM doesn't really appear at all (though it claims to be running), or it appears but somewhat corrupted; if you can get through the DM to the desktop, it will also be corrupted. Booting to runlevel 3 and starting the DM service manually, or dropping 'rhgb' from the kernel parameters, acts as a workaround. airlied says he has found the fix for this: https://patchwork.kernel.org/patch/1455231/ . He plans to run it by Ben and then submit it upstream.
Proposing as Beta blocker (conditional infringement of the 'live must boot' and 'installed system must boot' criteria in the case of certain NVIDIA adapters. We should commonbugs this for Alpha, as Alpha has the bug.
Created attachment 612728 [details] F18 Alpha Live KDE, loading sessiion
Created attachment 612729 [details] F18 Alpha Live KDE, session ready (Device notifier offering usb stick)
Captures made on Asus V1S laptop with GeForce 8600M GT (512MB VRAM). Alpha (RC3) is the first of GNOME/KDE Live TCs/RCs to run plymouth charge correctly on this hardware (bug 855557), despite leading to the present defect. Dropping 'rhgb' from the kernel parameters, acts as a workaround as you mentioned (raw tty messaging instead of any animation, then no graphic corruption, KDE loads fine and Desktop Effects are enabled by default). Safe graphics (vesa) acts as yet another workaround, loading plymouth text animation. All other routes -- except vesa -- lead to extreme slowness (bug 855560) on this hardware, for both GNOME and KDE Live spins. LXDE Live Alpha (RC3) just works as default, without any workaround, running plymouth charge. Is the present defect, only affecting desktop acceleration ?
I had this issue when installing TC5 and could not make heads of tails of it. I stumbled on a fix when I installed F17 and then "upgraded" to F18. When I boot with the old F17 kernel (3.5.3-1.fc17.x86_64) everything works perfectly, but with the F18 3.6 kernels I am lucky to get to a GDM and if I do it is a horrid mess. Booting to runlevel 3 and then launching the GDM did not help.
I've tested airlied's fix and it works for me. The scratch build I used to test is here: http://koji.fedoraproject.org/koji/taskinfo?taskID=4482706 feel free to grab it before it expires and check that it works for you too. thanks!
Patch is picked up in kernel-3.6.0-0.rc5.git3.1.fc18
On an installed system I never reproduced the graphics corruption, the system froze instead after login. kernel-3.6.0-0.rc5.git3.1.fc18 fixed the issue for me.
kernel-3.6.0-0.rc6.git0.2.fc18 has been submitted as an update for Fedora 18. https://admin.fedoraproject.org/updates/kernel-3.6.0-0.rc6.git0.2.fc18
Package kernel-3.6.0-0.rc6.git0.2.fc18: * should fix your issue, * was pushed to the Fedora 18 testing repository, * should be available at your local mirror within two days. Update it with: # su -c 'yum update --enablerepo=updates-testing kernel-3.6.0-0.rc6.git0.2.fc18' as soon as you are able to, then reboot. Please go to the following url: https://admin.fedoraproject.org/updates/FEDORA-2012-14273/kernel-3.6.0-0.rc6.git0.2.fc18 then log in and leave karma (feedback).
kernel-3.6.0-0.rc6.git0.2.fc18 has been pushed to the Fedora 18 stable repository. If problems still persist, please make note of it in this bug report.
May I confirm too, this is fixed on the hardware I reported. Tested Fedora-18-Beta-TC6-x86_64-Live-KDE.iso Thanks!