Bug 855083 - Fail to start graphical installation on cirrus card in qemu
Fail to start graphical installation on cirrus card in qemu
Product: Fedora
Classification: Fedora
Component: kernel (Show other bugs)
x86_64 Linux
unspecified Severity unspecified
: ---
: ---
Assigned To: Kernel Maintainer List
Fedora Extras Quality Assurance
AcceptedNTH RejectedBlocker
Depends On:
Blocks: F18Beta-accepted/F18BetaFreezeExcept 856728
  Show dependency treegraph
Reported: 2012-09-06 12:00 EDT by Jan ONDREJ
Modified: 2012-09-28 20:05 EDT (History)
11 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
: 856728 (view as bug list)
Last Closed: 2012-09-28 20:05:07 EDT
Type: Bug
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Attachments (Terms of Use)

  None (edit)
Description Jan ONDREJ 2012-09-06 12:00:07 EDT
Description of problem:
Xorg fails to start in qemu's default cirrus vga output.

Version-Release number of selected component (if applicable):
todays F18 installer, happened before too

How reproducible:

Steps to Reproduce:
1. Boot F18 installer using: qemu-kvm -vga cirrus ...
Actual results:
Starting installer, one moment...
anaconda 18.6.5 for Fedora 18 (pre-release) started.
15:57:08 X startup failed, falling back to text mode

Xorg.log output:
(EE) cirrus: The PCI device 0xb8 at 00@00:02:0 has a kernel module claiming it.
(EE) cirrus: This driver cannot operate until it has been unloaded.

Expected results:
graphical boot

Additional info:
I can use "nomodeset" boot option to workaround this, but this is not for normal users.
Comment 1 Robert Lightfoot 2012-09-10 07:56:51 EDT
Using virt-manager on a Centos 6.3 host I ran into same issue that F18-alpha-TC6-i386 would not boot using cirrus video.  MY work around was to switch to vga driver.
Comment 2 Kamil Páral 2012-09-10 08:01:14 EDT
Proposing as F18 Blocker:
" The release must install and boot successfully as a virtual guest in a situation where the virtual host is running the previous stable Fedora release, using Fedora's current preferred virtualization technology "

qxl is current default, but cirrus is still used in old VMs. I'm not really sure we want to block on both qxl and cirrus, so this should just start a discussion.
Comment 3 Adam Williamson 2012-09-26 13:26:05 EDT
The 'cirrus' driver shouldn't be used any more, it should be using the 'modesetting' driver.

I think we may have sorted this out in the live kickstarts but not in the package set used in the installer images, I guess.
Comment 4 Adam Williamson 2012-09-26 13:38:48 EDT
Discussed at 2012-09-26 blocker review meeting: http://meetbot.fedoraproject.org/fedora-qa/2012-09-26/f18-beta-blocker-review-1.2012-09-26-16.03.log.txt . We agreed that qxl has been the default long enough that cirrus bugs have a very high bar to clear to be taken as blocker, and this doesn't really clear it, as it's simple to workaround in many ways (pick a different adapter, or run the install in basic graphics mode or with nomodeset). So this is rejected as a blocker. However, it's accepted as NTH.
Comment 5 Robert Lightfoot 2012-09-27 08:47:36 EDT
Just to clarify and make sure I understand.  Is qxl supposed to be default on qemu/kvm if run from Centos 6?  I don't even get the qxl driver option in centos unless I switch from vnc video to spice video first.  I am thinking the Centos Default still has not caught up with the "Fedora Default".  I can agree though with the NTH as Centos qemu/kvm can do spice/qxl if you know to set it up.  Piece of minutesha for the Docs I guess.
Comment 6 Adam Williamson 2012-09-28 16:15:43 EDT
We didn't look into the CentOS case much. Honestly, for Fedora we mostly care about Fedora.

We're not entirely sure why the 'cirrus' driver was still in the environment and used for this test, to be honest. I'll try and find a minute to test with a few different images here, but we also think that:


should fix the case where both cirrus and modesetting are present, so that may be enough to resolve this. Needs more testing.
Comment 7 Adam Williamson 2012-09-28 20:05:07 EDT
So I just tested this with smoke3. It appears to have both cirrus and modesetting drivers installed, we'd have to look into the compose logs to figure why xorg-x11-drv-cirrus is being pulled in.

The good news, though, is that it looks like cirrus 1.5.1-3 fixes this: anaconda starts up fine, and the X log shows the cirrus driver loading up and then being unloaded because the cirrus kernel module is loaded, and X falls back to modesetting smoothly. So it seems that 1.5.1-3 is good, even with both the cirrus and modesetting drivers present, this will work. The only possibly dangerous scenario would be if we left the modesetting driver out of some compose or other. I'll mark this as fixed (1.5.1-3 is stable).

Note You need to log in before you can comment on or make changes to this bug.