Description of problem: If I install system using 'basic graphics mode', vesa is forced through nomodeset (that is correct), but not through Xorg conf file (that is not correct). There is no xorg.conf file and no related conf file neither in xorg.conf.d/. See this discussion: http://lists.fedoraproject.org/pipermail/test/2012-September/110078.html Version-Release number of selected component (if applicable): F18 Alpha How reproducible: always Steps to Reproduce: 1. follow https://fedoraproject.org/wiki/QA:Testcase_Anaconda_User_Interface_Basic_Video_Driver
Proposing as Beta blocker: " The boot menu for all installation images should include an entry which causes both installation and the installed system to use a generic, highly compatible video driver (such as 'vesa'). This mechanism should work correctly, launching the installer and attempting to use the generic driver " https://fedoraproject.org/wiki/Fedora_18_Alpha_Release_Criteria
I'm not entirely convinced. vesa isn't the correct fallback driver in all cases. On UEFI systems vesa simply won't work, and in that scenario an xorg.conf that explicitly requests vesa will result in X not launching at all. Given that UEFI systems are expected to be the vast majority of new hardware over F18's lifespan, setting them up to fail seems like a bad idea. Which actually suggests that "Basic graphics mode" may already be broken for UEFI. xserver doesn't currently have a way to express "skip your native driver detection and just give me the platform-appropriate fallback", but it's not hard to add. I'd rather see that than more X knowledge in anaconda.
ajax: well, the behaviour described in the thread and the test case is what the current code is actually supposed to do, and what happened in the past. the fact that it isn't actually happening is clearly a bug. but i'd be fine if we want to decide that instead of fixing the current intended behaviour, we should change the intended behaviour to 'tell X to force correct fallback', implement that on the X side, and fix anaconda/live boot to do that when using the 'basic graphics mode' boot option.
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 . This is rejected as a blocker because, though the absence of the xorg.conf.d snippet is clearly a bug, it has few practical consequences. The 'basic graphics driver' option also causes the 'nomodeset' kernel parameter to be passed at boot time. These days, virtually all X drivers (and all for common hardware) no longer have UMS code. So if you boot with KMS disabled (which is what nomodeset does), these drivers will not work, and X will wind up falling back to vesa anyway. Practically speaking, just passing 'nomodeset' is enough to cause the fallback driver to be used in almost all cases, so we don't think this bug needs to block the Beta release. The bug is also rejected as NTH: the changes to fix it are likely not trivial, and the fix would have little practical consequence, as described above, so it's not appropriate for NTH status. It should be fixed outside of freeze.
I tested F18 live image on system with gma3600 but X server fails to start because it tries to load intel driver instead of modesetting. So I tried xdriver=modesetting and xdriver=vesa kernel parameters but X server still tries to use intel driver.
Created attachment 635778 [details] Xorg.0.log with xdriver=vesa
As discussed earlier in this bug, the 'basic graphics mode' option should at least get you booted. Did you try that?
I selected "Started Fedora 18 in basic graphics mode" but X fails to start with almost the same log as in Comment 6. Only nomodeset parameter added to xdriver=vesa.
Ah. I think X's autodetection code needs an exception to *not* try and load the intel driver for this adapter. I'm assuming it already has exceptions for older Poulsbo-type adapters.
ajax: so, uh, any chance we might get around to doing what you said would be pretty easy in comment #2, any time this year? :) Be nice to finally have this fixed for F20.
At this point 'nomodeset' on kcmdline should be all you need to say, since we basically don't support non-KMS drivers anymore.
that is how we've set up F20, unless I missed any paths; all 'basic graphics mode' options should now simply pass 'nomodeset' and nothing more.
When running live image in vmware xdriver=vesa really forces X server to use vesa, but with nomodeset X server uses vmware driver, so nomodeset in this case not equal xdriver=vesa.
yeah, it may be the same in other virt environments, but then fallback graphics rarely makes any actual sense for use in virt, so it doesn't seem like a big issue.