Description of problem:
Booting the F16 Beta, Final TC2 KDE x86_64 live image inside a virt-manager VM - host
F15, F16, using the cirrus video adapter - results in KDE crashing right at
the end of startup (after it displays the KDE logo in the bootsplash sequence) giving a black screen.
Booting in 'basic graphics mode' - i.e. using vesa instead of the cirrus
driver - works.
Version-Release number of selected component (if applicable):
Steps to Reproduce:
1. Boot the live CD
2. Log in
3. After the initialisation plasma crashes
This bug is possible related to bug #731245. The cirrus-driver is the default when installing a new VM.
Created attachment 530548 [details]
Created attachment 530549 [details]
Created attachment 530550 [details]
Created attachment 530551 [details]
er, kdm.log shows a backtrace in qxl, not cirrus. are you sure this is using cirrus? are you sure you have the right logs?
Fedora Bugzappers volunteer triage team
As with the qxl bug, this only happens with the (new) default of "QT_GRAPHICSSYSTEM=raster" - see bug #731245 comment #32.
Arch, I'll create a new kdm.log from TC3 final. Sorry :-(
updating the summary, nominating as a blocker, because F15 defaults to cirrus/vnc not qxl/spice, unfortunately :( as we 'support' both F-N and F-N-1 as virt hosts in the criteria, we need both cirrus and qxl drivers to work with raster, so KDE will run on both F15 and F16 KVM host default configs.
Fedora Bugzappers volunteer triage team
to reproduce this, btw, just create a VM in Fedora 15 virt-manager with all default settings and try to boot an F16 live KDE image. that should be all that's needed.
To expand on Oliver's comment #6: Qt's default rendering engine changed from 'native' (which uses Xrender) to 'raster' (software rasterization) in Qt 4.8, and that's what 'broke', here (why this works in F15 and not F16). Switching back to 'native' by default would be sub-optimal for reasons discussed in https://bugzilla.redhat.com/show_bug.cgi?id=731245#c85 , so we really want the cirrus driver to be fixed with respect to Qt's 'raster' rendering, that would be the best solution. thanks!
I can reproduce this using either the 32- or 64-bit TC3 Live KDE image booted in either a 32- or 64-bit F16 KVM guest (both default installs from the respective TC3 DVDs). My host is F15 x86_64. As long as the guest video driver is set to cirrus, it happens, with the display being set to either VNC or Spice. Booting the 64-bit Live always results in a black screen, while booting the 32-bit Live usually results in a crosshatch pattern (though I did see a black screen the first time booting it).
Attached below are logs associated with the 64-bit TC3 Live KDE image booted in the 64-bit F16 KVM guest, using VNC+cirrus. I got a black screen.
Created attachment 530603 [details]
Created attachment 530604 [details]
Created attachment 530605 [details]
Adding CCs for blocker votes. I'm +1 on this, given that cirrus seems to be the default for at least 32-bit VMs in both F15 and F16, and possibly 64-bit in F15.
Created attachment 530639 [details]
dmesg from final TC3 guest
Created attachment 530640 [details]
kdm.log from final TC3 guest
Created attachment 530641 [details]
messages from final TC3 guest
Created attachment 530642 [details]
Xorg.0.log from final TC3 guest
Created attachment 530643 [details]
xsession-errors from final TC3 guest
abrt created a core-dump. Is this info interesting? What files?
Reproduced. +1 blocker.
Discussed at 2011-10-28 blocker review meeting. Accepted as a blocker per criterion "Following on from the previous criterion, after firstboot is completed and on subsequent boots, a system installed according to any of the above criteria (or the appropriate Beta or Final criteria, when applying this criterion to those releases) must boot to a working graphical environment without unintended user intervention. This includes correctly accessing any encrypted partitions when the correct passphrase" as applied to the KDE desktop + cirrus driver combination.
We have significant progress here. We're pretty sure it's:
rdieter is working on a Qt build with that patch to test.
Found the aforementioned commit,
Test build underway:
snarf over to qt
qt-4.8.0-0.23.rc1.fc16 has been submitted as an update for Fedora 16.
I tested the fix, it looks good. I'm uploading a new live image with the fix included.
If you want to test the fix for this, grab http://adamwill.fedorapeople.org/adamwkde-20111028-x86_64.iso (sha256sum 97a4d9429ec4e06cbb9d3ebeb010fd044ae66d49abeb58915714bb8f4cb49594 ). It has the fix for this and the fix for the qxl bug, so both qxl and cirrus VMs should work with it. Works for me.
qt-4.8.0-0.23.rc1.fc16 has been pushed to the Fedora 16 stable repository. If problems still persist, please make note of it in this bug report.
Removing external tracker bug with the id '21754' as it is not valid for this tracker