Bug 628239

Summary: Fedora 14 Alpha "reduced graphics" creates vesa-using xorg.conf but doesn't blacklist nouveau
Product: [Fedora] Fedora Reporter: D.S. Ljungmark <spider>
Component: anacondaAssignee: Brian Lane <bcl>
Status: CLOSED CURRENTRELEASE QA Contact: Fedora Extras Quality Assurance <extras-qa>
Severity: medium Docs Contact:
Priority: low    
Version: 14CC: airlied, ajax, anaconda-maint-list, awilliam, bcl, bskeggs, fdc, jlaska, jonathan, vanmeeuwen+fedora
Target Milestone: ---Keywords: Triaged
Target Release: ---   
Hardware: All   
OS: Linux   
Whiteboard:
Fixed In Version: Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2010-09-16 06:42:14 UTC Type: ---
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---
Bug Depends On:    
Bug Blocks: 611991    

Description D.S. Ljungmark 2010-08-28 22:02:33 UTC
Description of problem:
Fresh installation from a Fedora 14 alpha DVD.


After installation, the boot proceeds normally, however once X is to start, I get graphical corruption.

Checking further showed that /var/log/Xorg.0.log only referenced to vesa driver.

Looking in /etc/X11/xorg.conf showed that something had created a very simplitic xorg.conf that only referenced an Identifier and set the "vesa" driver.

Comment 1 François Cami 2010-08-28 22:11:43 UTC
Could you confirm that removing that file solved the problem, as in, you could get into gdm and a graphical session?

Thanks


--
Fedora Bugzappers volunteer triage team
https://fedoraproject.org/wiki/BugZappers

Comment 2 D.S. Ljungmark 2010-08-28 22:13:03 UTC
Removing the file solves the issue and I get a crisp&clear login window at the next reboot.

Comment 3 François Cami 2010-08-28 22:16:01 UTC
Thank you.

Comment 4 D.S. Ljungmark 2010-08-28 22:28:40 UTC
Just a note:  I installed using the "reduced graphics "  option from the DVD, 
Not sure if that'd have any bearing on this at all.


And to clarify: 
   I used the Fedora 14 Alpha media ( not the live dvd)
    Reduced graphics mode on the DVD install :  works
    Post installation vesa graphics in Xorg:  corrupted

rpm -q kernel xorg-x11-drv-nouveau xorg-x11-server-Xorg xorg-x11-drv-vesa

kernel-2.6.35.2-9.fc14.x86_64
kernel-2.6.35.4-12.fc14.x86_64
xorg-x11-drv-nouveau-0.0.16-9.20100615gitdb98ad2.fc14.x86_64
xorg-x11-server-Xorg-1.9.0-4.fc14.x86_64
xorg-x11-drv-vesa-2.3.0-1.fc14.x86_64

Comment 5 François Cami 2010-08-28 22:39:23 UTC
Could you post the output of "cat /proc/cmdline" if you haven't modified it since the install?

For the record, my hunch is that we should blacklist the radeon and nouveau kernel modules in the installed system if the user selects "reduced graphics", but somehow we don't.

Switching component to anaconda.

--
Fedora Bugzappers volunteer triage team
https://fedoraproject.org/wiki/BugZappers

Comment 6 Chris Lumens 2010-08-29 04:11:13 UTC
Are either of those modules even loaded?

Comment 7 D.S. Ljungmark 2010-08-30 01:01:23 UTC
nouveau was loaded and running.

Kernel command line: root=UUID=c4c2b36c-2579-4d43-9c68-ea500bad3107 LANG=en_US.UTF-8 SYSFONT=latarcyrheb-sun16 KEYBOARDTYPE=pc  KEYTABLE=sv-latin1 ro rhgb quiet

Comment 8 François Cami 2010-08-30 08:38:57 UTC
Chris, instead of blacklisting the kernel modules, we probably need "nomodeset" (exactly as in syslinux.cfg).

Comment 9 Adam Jackson 2010-08-30 21:05:29 UTC
That should be pulled in from /proc/cmdline when grubby runs, I would think.

Comment 10 Adam Williamson 2010-09-03 15:56:09 UTC
fcami's suggestion seems correct to me, we should probably test to see exactly what happens at present if you install with basic graphics.

Comment 11 Adam Williamson 2010-09-03 16:54:07 UTC
Discussed at today's blocker review meeting. If the bug is as described, we would accept it as a blocker, after extending the alpha criterion "The graphical 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" to note that the installed system must also be configured to use the vesa driver. We'd like to test independently and confirm the behaviour is in fact as described in the report, though.

Comment 12 D.S. Ljungmark 2010-09-03 17:05:14 UTC
Please do, and good to see a followup.

Comment 13 John Poelstra 2010-09-09 04:35:30 UTC
What are the plans for addressing and assessing this bug?  We'd love to have more information before the next blocker meeting this Friday.

Comment 14 François Cami 2010-09-09 06:30:34 UTC
I'll test the latest compose tonight and see if the nomodeset parameter is kept post-install time.

--
Fedora Bugzappers volunteer triage team
https://fedoraproject.org/wiki/BugZappers

Comment 15 François Cami 2010-09-09 19:18:58 UTC
John,

All I get is a black screen with xdriver=vesa nomodeset in a KVM guest, and I will not have the time to try to reproduce on real hardware before the blocker meeting.

--
Fedora Bugzappers volunteer triage team
https://fedoraproject.org/wiki/BugZappers

Comment 16 Adam Williamson 2010-09-09 19:49:28 UTC
francois: that's a known bug in qemu/kvm. I'll try and find some time to test this by installing to USB key soon.

Comment 17 Brian Lane 2010-09-10 23:58:14 UTC
I tried this out with F14 Beta TC1 on my system.

00:10.0 VGA compatible controller: nVidia Corporation C73 [GeForce 7050 / nForce 610i] (rev a2)

Installed with the basic video driver option to an external USB drive. It use GUI mode, 800x600, with no problems.

On boot it was running firstboot on tty6 and gdm on tty1. After switching away from firstboot I could not return to it. It locked up -- I could see a text console, but couldn't do anything. On reboot I was on tty1, but firstboot was on tty6 still so I ran through it and setup a user.

After firstboot the display turned off, no signal and I had to do a hard reboot.

The system came back up with tty1 and gdm. I logged in and the grapics look fine. It was using 800x600 mode.

I also see a warning (not sure from what) saying 'Monitor Error. Could not switch monitor configuration. Requested (1,1) ... min(640,480) max(800x600)

(this is from notes, not verbatim).

The nouveau module was running, although that didn't seem to be causing any problems. I added it to /etc/modprobe.d/blacklist.conf and rebooted. It wasn't blacklisted, it was still running. I removed it using modprobe -r and the system continued to work just fine).

I then re-installed with the non-basic video. anaconda used a higher resolution, install went fine. After the install I had similar results to the first time, but it came up on tty1 first and then I switched to tty6 and completed firstboot.



So, I don't see any problems with the nouveau module running while X is using vesa mode. There does seem to be some problem with firstboot, and I've filed a bug on it. bug 632685

Comment 18 Adam Williamson 2010-09-13 18:18:05 UTC
I can't reproduce with TC1 either. It works fine. It writes xorg.conf with Driver "vesa" and adds nomodeset to the kernel parameters, which is all it needs to do. There is no need to blacklist nouveau, the module can be loaded as long as KMS is disabled.

So I don't think this bug is valid as described in TC1. Reporter, can you try with TC1 and see how it behaves? http://serverbeach1.fedoraproject.org/pub/alt/stage/14-Beta.TC1/



-- 
Fedora Bugzappers volunteer triage team
https://fedoraproject.org/wiki/BugZappers

Comment 19 D.S. Ljungmark 2010-09-13 20:02:59 UTC
Downloading now, will try and see either tomorrow morning (tuesday) or Wednesday evening. Best I can offer.

Comment 20 Adam Williamson 2010-09-14 18:39:23 UTC
Discussed at today's interim blocker review meeting: we agreed that this seemed to be working correctly in all our testing, so we need new info from the reporter to continue to consider this as a blocker. For now we'll leave it on the list, but without new info it will likely be dropped.

Comment 21 D.S. Ljungmark 2010-09-16 05:24:04 UTC
Verified with the Beta.TC1 build image, and this issue is resolved.