Description of problem: With default xorg.conf, once X is entered, Ctrl+Alt+Fn results in a blank screen. Doint Ctrl+Alt+F7 brings back X OK. With VBERestore set to yes, the situation is slightly different. Once X is entered, Ctrl+Alt+Fn brings up VTs, but it is impossible to go back to X (i.e. blank screen on Ctrl+Alt+F7). X is still running, of course, and blind typing will log you in, but no pretty pictures :-( Version-Release number of selected component (if applicable): xorg-x11-6.8.2-37 How reproducible: Always. Steps to Reproduce: 1. Bring up X. 2. Attempt to switch to text VT. Actual results: Blank screen. Expected results: Text console. Additional info: N/A
Me too. FC4 Intel 82852/855GM integrated graphics card. Can't see any virtual consoles on the screen (can type, though). Can switch back to X. If I boot to init 3, I can startx to X, but get a blank screen after closing X. I can still give commands (including startx to get X back again), but I'd like to be able to see what I'm doing!
another Me too using the 865G video driver.
and another "me too" for the black terminal.. Using intel 82865G also
Same story here.. Intel 845G.
The X.org bug related to this is here: https://bugs.freedesktop.org/show_bug.cgi?id=3094
Anybody care to try the workaround offered in Bug 2991 (same problem, different video cards) comment #32 on x.org bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=2991 ("Take /usr/X11R6/lib/modules/libvgahw.a from an up-to-date Fedora Core 3 (xorg-x11-6.8.2-something) and overwrite the file on Fedora Core 4 Test 3. With that, the virtual consoles problem does not occur anymore (Matrox MGA G400). No green border or green screen anywhere either.") I'm not with the machine that's giving the problem at the moment, so I can't try this out until tonight.
The above worked for me!! (i845G)
The procedure from comment #6 fixed the problem here (i865G).
Yup, that works for me too. So we've got a workaround until this gets fixed, at least!
I tried with an intel 815 and problem with terminals disappeared. I have an 865G, I am glad that it works there also. Removing from CC
Created attachment 115601 [details] Log file when loading with FC3 libvgahw.a
I tried comment #6 too, but didn't work for me. Configuration Fujitsu-Siemens L6810 with Intel 845G. Fedora Core 4. I used the libvgahw.a from the FC3 updates xorg-x11-6.8.2-1.FC3.13.i386.rpm. X is not able to load this lib (see attached Xorg.0.log) cheers Lars
Lars said: > X is not able to load this lib (see attached Xorg.0.log) [Lars' log]: (II) Loading sub module "vgahw" (II) LoadModule: "vgahw" (II) Loading /usr/X11R6/lib/modules/libvgahw.a (EE) /usr/X11R6/lib/modules/libvgahw.a is an unrecognized module type (II) UnloadModule: "vgahw" (EE) I810: Failed to load module "vgahw" (unknown module type, 6) Very odd. Can you md5sum that libvgahw.a that you've got - it should work OK. Can somebody md5sum a working FC3 libvgahw.a to check (Sven? Pedro?)? I'm away from my FC boxes. Double-check that you aren't mixing architechures (i386/ x86_64/ ppc!).
(In reply to comment #13) > > Very odd. Can you md5sum that libvgahw.a that you've got - it should work OK. Right, it does, if one makes no errors in extracting files from the rpm. I forgot a simple dot and so the file size of lib was zero. Of course X is not able to load data from a zero size lib. ;-) So here's a small step by step to prevent other from making the same mistake -become root and cd to roots home $cd -make a backup of libvga.a $cp /usr/X11R6/lib/modules/libvgahw.a /usr/X11R6/lib/modules/libvgahw.a.org -get the last FC3 xorg X11 (maybe you have to choose another ftp server or another platform) $wget ftp://ftp-stud.fht-esslingen.de/pub/Mirrors/fedora.redhat.com/linux/core/updates/3/i386/xorg-x11-6.8.2-1.FC3.13.i386.rpm -extract the libvgahw.a from the rpm (here I missed the dot in front of /usr) $rpm2cpio xorg-x11-6.8.2-1.FC3.13.i386.rpm | cpio -ivd ./usr/X11R6/lib/modules/libvgahw.a -copy it to the right place $cp ./usr/X11R6/lib/modules/libvgahw.a /usr/X11R6/lib/modules/libvgahw.a -remove rpm and temprary lib (be carefull not to delete your /usr!) $rm -rf ~/usr $rm xorg-x11-6.8.2-1.FC3.13.i386.rpm -restart your X server -> Done! cheers Lars
A perhaps simpler way (all a matter of taste, of course) to get the file is to use the Archive Manager program to extract it.
md5sum of an installed binary will change depending on if and how the system has been prelinked or not. In theory, every system could legally result in completely different md5sums and still have legit binaries. This is the nature of prelinking. Not sure if these modules specifically get prelinked or not however, but I just wanted to indicate that that is not a reliable method of comparing things for authenticity. Use "rpm -V" instead.
Bojan: Please try replacing the libvgahw.a module (after backing up the original), with the following one: ftp://people.redhat.com/mharris/libvgahw.a This one is taken from the latest FC3 errata release, and many people claim it solves the problem. If you could confirm this for me, it would help us in solving the problem for a future update. Thanks in advance. Setting status to "NEEDINFO"
Shall do. I just didn't have any pressing need to try that out, given that this particular system is destined for a rubbish bin anyway :-)
Yes, it works on this box too.
Mike,the above libvgahw.a worked on my box as well.
Ok, thanks a bunch everyone! Please add yourselves to the CC list of bug #161242 if you'd like to keep track of the status of the underlying bug we're investigating. I suspect it wont be long until we find a solution now, and release an update. Thanks again! *** This bug has been marked as a duplicate of 161242 ***
I have an Fujitsu-Siemens Amilo L laptop with an integrated Intel 82845G graphics card. I have the same problem. The screen goes blank when I shut down and I have blank virtual terminals. In addition I have problems when entering graphics mode during boot up. The screen flickers three times before entering the progress bar screen. When entering the login screen it flickers for four times.
This bug is closed as a duplicate of bug #161242. Please see that master bug for a workaround for this problem.