Bug 628239

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

Removing the file solves the issue and I get a crisp&clear login window at the next reboot.

Thank you.

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

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

Are either of those modules even loaded?

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

Chris, instead of blacklisting the kernel modules, we probably need "nomodeset" (exactly as in syslinux.cfg).

That should be pulled in from /proc/cmdline when grubby runs, I would think.

fcami's suggestion seems correct to me, we should probably test to see exactly what happens at present if you install with basic graphics.

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.

Please do, and good to see a followup.

What are the plans for addressing and assessing this bug?  We'd love to have more information before the next blocker meeting this Friday.

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

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

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.

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

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

Downloading now, will try and see either tomorrow morning (tuesday) or Wednesday evening. Best I can offer.

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.

Verified with the Beta.TC1 build image, and this issue is resolved.