Description of problem:
I booted today's rawhide. X is... weird.
Best description is as if the screen has been scaled to 320x200, no dithering.
It's actually running at the right resolution, though. Progress bars look
normal, but icons/images and fonts most assuredly do not.
i965, attached to Dell 2005FPW, via DVI.
Version-Release number of selected component (if applicable):
Created attachment 292055 [details]
Created attachment 292056 [details]
your standard anaconda X config
Created attachment 292057 [details]
log. neither big, nor heavy, nor wood
Option "AccelMethod" "XAA" fixes it post-install. Presumably it would fix it
during install as well.
In testing, this either requires (IIRC) EXA + DRI, or XAA + NoDRI, to work.
Still happens in rawhide-20080314.
*** Bug 437910 has been marked as a duplicate of this bug. ***
*** Bug 438952 has been marked as a duplicate of this bug. ***
*** Bug 436746 has been marked as a duplicate of this bug. ***
*** Bug 439149 has been marked as a duplicate of this bug. ***
*** Bug 439377 has been marked as a duplicate of this bug. ***
Zhen Gang Li <firstname.lastname@example.org> - 2008-03-26 22:19 EDT
Fedora 9 beta install DVD disc inserted to a Lenovo desktop. In the graphic
installer mode, the screen is white blank, with the cursor icon on it. All text
and graphics are not visible. Cursor icon is responsive to mouse movement.
Found only a Lenovo desktop with the following config:
Machine type: 8810-BK7
Cpu type: IA-32 (Intel Core 2 Duo 6300 1.86GHz)
System has an NTFS windows partition and a previous OpenSUSE 10.3 install on
two ext3 partition.
Is this reproducible?
Yes. But only on a desktop with the mentioned config.
Describe the steps:
1. Boot the Fedora 9 DVD disc, select the default install mode (not the text
2. Wait till the graphics installer starts
3. The screen will be white blank.
Is the system (not just the application) hung?
No, Cursor icon is responsive to mouse movement.
Cijurajan Kollanoor <email@example.com> - 2008-03-27 06:51 EDT
Had you seen the same problem in any of the previous Fedora versions?
Could you see any error messages in any of the console? If yes, please attach
it to the bugzilla report.
Zhen Gang Li <firstname.lastname@example.org> - 2008-03-28 01:49 EDT
I inserted a Fedora 8 DVD install disc. It displays a correct welcome graphic
F9 install doesn't have any error log on the console screen. Because it's X
window related, I attached the /tmp/X.log together with syslog & anaconda.log here.
Zhen Gang Li <email@example.com> - 2008-03-28 01:50 EDT
X server log
Zhen Gang Li <firstname.lastname@example.org> - 2008-03-28 01:51 EDT
Zhen Gang Li <email@example.com> - 2008-03-28 01:52 EDT
Zhen Gang Li <firstname.lastname@example.org> - 2008-03-28 02:32 EDT
Yes. That's where I copied the log files (from Ctrl-Alt-F2 console). No extra
*** This bug has been marked as a duplicate of 429183 ***
Created attachment 299495 [details]
Created attachment 299496 [details]
Created attachment 299497 [details]
X server log
How could it have priority low?
With huge number of notebooks with X3100 on the market F9 should not be released
with this bug! A lot of users won't be able to install with GUI and will
switch to other distros.
*** Bug 440037 has been marked as a duplicate of this bug. ***
The same bug exists in Fedora 9 beta.
*** Bug 440186 has been marked as a duplicate of this bug. ***
Bug 440186 is from ATI, so I tend to blame the server itself. Reassigning.
Matej, bug 440186 looks like a very different bug. 440186 didn't occur during
Anaconda install; DRI loaded correctly; it's using XAA acceleration rather than
EXA; and it's not on an Intel chip, unlike all of the other bug reports.
Created attachment 300296 [details]
Script to build a new F9 beta DVD ISO that works correctly with i965 gfx
The attached f9fix.sh script will modify the F9 beta DVD ISO to add the
"AccelMethod XAA" directive to the X configuration file during Anaconda launch.
This allows graphical installs to start successfully on my Thinkpad T61 8897
with i965/X3100 graphics.
The script has only been tested with the x86_64 ISO. However, there is an
attempt in the code to make it work for 32-bit installs. To run it, you will
need about 10GiB of free disk space to build the new ISO image.
The script is just a hack to get the installer working. Based on the
information in this bug, it looks like the real fix is to modify the Intel X
driver to fall back to XAA if the DRI module doesn't load. But, I am not so
masochistic as to try to set up a cross-compiled x86_64 X development
environment from scratch here.
This is actually much better with the current intel driver and EXA.
------- Comment From email@example.com 2008-04-11 02:47 EDT-------
Sorry, I don't have that much of free space on my workstations. Is there
anyway that can update the disk content without having regenerate the iso
itself. I was thinkin of changing the file after the iso is booted. But I
don't have a clue where to pause the norml start process.
*** Bug 442940 has been marked as a duplicate of this bug. ***
I'm having the same problem. Just created 442940. I'll post my dmesg and Xorg
log trying to help guys.
Created attachment 302785 [details]
Another dmesg sample. Hope it helps somehow.
Created attachment 302786 [details]
Another X server log
One more X server log...
Rebuilding the current intel driver with EXA and rebuilding the installer image
yields the following.
Created attachment 302889 [details]
Created attachment 302890 [details]
Definetly an improvement, nice work.
Googling around, look what I found:
Perhaps a brief email to Carl Worth may help us? He does have a @redhat email...
Bill - how are things looking now?
Identical to comment #32/#33.
The liveCD is similar. The installation from the liveCD is normal. This is where
Bill, I got the problem while running the installation from LiveCD. Check bug
#442940 for a report.
No, what I mean is *once you have finished installing* the system from the
liveCD, it's OK.
Given that, and that the display is navigable, I'm not considering this a
release blocking issue at this point. Moving to target.
However, just to document:
- the livecd renders in the way shown in the above graphics
- an install from such a livecd renders correctly
Comparing the Xorg.0.logs from the two cases shows *zero* differences.
Aaaaaaand for the clincher.
If the 'installed' system (which normally renders correctly) is booted from
isolinux instead of from grub, the rendering artifacts show up.
No, I do not know why.
If isolinux is booted without the VESA graphical menu, it also renders normally.
Jesse Barnes implies that even though this is triggered by the bootloader
change, it is still a driver issue, as it's not fully initializing the 3D state
needed for render accel, and is inheriting bad stuff from the BIOS. Back to the
Created attachment 304907 [details]
register dump when booted from grub
Here's the working register dump.
Created attachment 304908 [details]
register dump when booted from isolinux
Here's the register dump when it doesn't work.
Changing version to '9' as part of upcoming Fedora 9 GA.
More information and reason for this action is here:
This can be resolved on a USB key with the following:
- Copy /usr/lib/syslinux/menu.c32 to syslinux/ on the key
- Make the following changes to syslinux/syslinux.cfg on the key:
* Modify the line starting with "default" to read "default menu.c32"
* Comment out or remove the line starting with "menu background"
Just wanted to say that I have the same problem with the final release. I
tested the previuos beta releases and never saw this problem.
It's a relieve to know that it works fine after doing a final installation on
the hard drive.
For me lspci shows the following:
00:02.0 VGA compatible controller: Intel Corporation 82Q963/Q965 Integrated
Graphics Controller (rev 02)
This is fixed in F10. I don't recall *what* release of the driver fixed this, but it is fixed.