Bug 628239 - Fedora 14 Alpha "reduced graphics" creates vesa-using xorg.conf but doesn't blacklist nouveau
Fedora 14 Alpha "reduced graphics" creates vesa-using xorg.conf but doesn't b...
Status: CLOSED CURRENTRELEASE
Product: Fedora
Classification: Fedora
Component: anaconda (Show other bugs)
14
All Linux
low Severity medium
: ---
: ---
Assigned To: Brian Lane
Fedora Extras Quality Assurance
: Triaged
Depends On:
Blocks: F14Beta/F14BetaBlocker
  Show dependency treegraph
 
Reported: 2010-08-28 18:02 EDT by D.S. Ljungmark
Modified: 2010-09-16 02:42 EDT (History)
10 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2010-09-16 02:42:14 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)

  None (edit)
Description D.S. Ljungmark 2010-08-28 18:02:33 EDT
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 18:11:43 EDT
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 18:13:03 EDT
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 18:16:01 EDT
Thank you.
Comment 4 D.S. Ljungmark 2010-08-28 18:28:40 EDT
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 18:39:23 EDT
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 00:11:13 EDT
Are either of those modules even loaded?
Comment 7 D.S. Ljungmark 2010-08-29 21:01:23 EDT
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 04:38:57 EDT
Chris, instead of blacklisting the kernel modules, we probably need "nomodeset" (exactly as in syslinux.cfg).
Comment 9 Adam Jackson 2010-08-30 17:05:29 EDT
That should be pulled in from /proc/cmdline when grubby runs, I would think.
Comment 10 Adam Williamson 2010-09-03 11:56:09 EDT
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 12:54:07 EDT
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 13:05:14 EDT
Please do, and good to see a followup.
Comment 13 John Poelstra 2010-09-09 00:35:30 EDT
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 02:30:34 EDT
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 15:18:58 EDT
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 15:49:28 EDT
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 19:58:14 EDT
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 14:18:05 EDT
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 16:02:59 EDT
Downloading now, will try and see either tomorrow morning (tuesday) or Wednesday evening. Best I can offer.
Comment 20 Adam Williamson 2010-09-14 14:39:23 EDT
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 01:24:04 EDT
Verified with the Beta.TC1 build image, and this issue is resolved.

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