Bug 712180

Thanks for the bug report.  We have reviewed the information you have provided above, and there is some additional information especially concerning your hardware we require that will be helpful in our diagnosis of this issue.

If the computer is not completely frozen when installation fails, switch to the console (Ctrl+Alt+F2) and copy /tmp/X* and /var/log/anaconda.xlog to some other place -- USB stick, some other computer via network, somewhere on the Internet, and please attach it to the bug report as individual uncompressed file attachments using the bugzilla file attachment link above.

If the computer is completely useless after installation fails, you can also install Fedora with a VESA mode driver (see http://docs.fedoraproject.org/en-US/Fedora/13/html/Installation_Guide/
for more information on that). Then after successful installation you can collect /var/log/anaconda.xlog, /var/log/Xorg.0.log, and the output of the program dmesg instead.

Or you can install Fedora in a text mode completely, and then start X after that. If it fails, still /var/log/Xorg.0.log and the output of dmesg program from the failed attempt to start X would be useful.

We will review this issue again once you've had a chance to attach this information.

Thank you very much in advance.

Created attachment 504077 [details]
Xorg log

Thanks for the concern. Well, installation didn't fail. I managed to install with Basic Video Settings option and now I am on Fedora 15. The issue is that when I try to install normally my laptop screen goes off. Now (after I login after the installation) the screen is stretched. And by default the system boots with nomodeset argument set. If I remove it the screen goes off.

The log file I have attached is the file after I login to GNOME.

This is most likely issue in kernel, and that isn't covered in /var/log/Xorg.0.log you gave us.

Please add drm.debug=0x04 to the kernel command line, remove nomodeset, restart computer, and attach from failed attempt

* your X server config file (/etc/X11/xorg.conf, if available),
* X server log file (/var/log/Xorg.*.log)
* output of the dmesg command (if you manage to get to the command line somehow - Ctrl-Alt-F2 or ssh), and
* system log (/var/log/messages)

to the bug report as individual uncompressed file attachments using the bugzilla file attachment link above.

We will review this issue again once you've had a chance to attach this information.

Thanks in advance.

I attached drm.debug=0x04 and removed nomodeset. Then the screen was hardly visible. So I set drm.debug=0x004 and nomodeset.

Created attachment 504163 [details]
Xorg.0.log

Created attachment 504165 [details]
Xorg.1.log

Created attachment 504168 [details]
Xorg.2.log

Created attachment 504171 [details]
Xorg.3.log

Created attachment 504172 [details]
Xorg.4.log

Created attachment 504173 [details]
Xorg.5.log

Created attachment 504174 [details]
Xorg.9.log

Created attachment 504175 [details]
dmesg

Created attachment 504178 [details]
system log

(In reply to comment #5)
> I attached drm.debug=0x04 and removed nomodeset. Then the screen was hardly
> visible. So I set drm.debug=0x004 and nomodeset.

I am sorry, I should be more explicit about that. That removing of nomodeset was not meant to be used permanently, but just for the one case so that we can get logs with the kernel messages showing us what is wrong. nomodeset switches off all kernel parts of X driver, so we don't get any information about what's wrong.

So yes, removing nomodeset will probably make your screen very dim (does it mean that the backlight of your LCD monitor is switched off?), but I hope it could be enough for you to login in the text console and run

dmesg >dmesg.out


and switching off the computer. That dmesg.out would be very helpful to us.

Thank you

Created attachment 504230 [details]
dmesg.out (without nomodeset)

(In reply to comment #15)
> (In reply to comment #5)
> > I attached drm.debug=0x04 and removed nomodeset. Then the screen was hardly
> > visible. So I set drm.debug=0x004 and nomodeset.
> 
> I am sorry, I should be more explicit about that. That removing of nomodeset
> was not meant to be used permanently, but just for the one case so that we can
> get logs with the kernel messages showing us what is wrong. nomodeset switches
> off all kernel parts of X driver, so we don't get any information about what's
> wrong.
> 
> So yes, removing nomodeset will probably make your screen very dim (does it
> mean that the backlight of your LCD monitor is switched off?), but I hope it
> could be enough for you to login in the text console and run
> 

Nope it is dim. When it is in dim I can switch off the monitor and I can see a difference. So it is dim and not switched off

> dmesg >dmesg.out
> 
> 
> and switching off the computer. That dmesg.out would be very helpful to us.
> 
> Thank you

I have attached the dmesg as dmesg.out and this file is when nomodeset is off

I followed the discussion[1] and added "acpi_osi=Linux" at the end of the kernel line at boot up (without nomodeset). Initially the screen was dim. Then I tried to change the brightness with my keyboard shortcuts. And it worked. But there was still an issue. When I press brightness up shortcut the brightness went down and when I press brightness down shortcut the brightness went up. However I managed to make it visible. And the GNOME3 functionality is there. It's no more fail safe mode.

Then I restarted without nomodeset and acpi_osi=Linux, and it works fine now.

What I suspect is that at boot up system tries to give the maximum brightness. For me that is the minimum brightness (because keyboard shortcuts worked completely the opposite way). Earlier when the screen was dim I tried to adjust the brightness with keyboard shortcuts but didn't work. So acpi_osi=Linux has done something. And now the systems functions well even without acpi_osi=Linux. Now (without acpi_osi=Linux) I can't change the screen brightness with keyboard shortcuts, the progress bar in the popup works but the brightness is not adjusted.

I hope this will give you some clues to figure out where things went wrong and I am happy provide you any information and see this bug fixed.

1 - http://www.fedoraforum.org/forum/showthread.php?t=247355

Thanks

I have to have acpi_osi=Linux as an kernel argument all the time and initially the screen is all black. I have to adjust the brightness with keyboard shortcuts all the time.

Same problem here, Acer Aspire 5736, f15 w/ current updates.

Notes:

1) without i915.modeset=0 the backlight does appear to start in the off position.  Hitting Fn-brighter once turns it back on.  On my keyboard, brighter is Fn-left-arrow and dimmer is Fn-right-arrow, which is different than I usually see.  

2) Starting with kernel modesetting gets me a graphical console that works fine until X tries to start.

3) X won't start with kernel modesetting, either automatically or from runlevel 3.  X -configure fails.  With nomodeset 1024x768 is the only available resolution once logged in to a session.  Of note, kdm comes up at the correct resolution with nomodeset but once the X session starts it falls back to 1024x768.

4) acpi_osi=Linux is required for the backlight keys to function.  I see no lasting benefit to having turned it on and off as described in Comment #18 - still doesn't work with it off here.

5) same symptoms booting from the F15 DVD.  nomodeset option works at reduced resolution, black screen with default graphical installer.

6) Fedora 14 LiveCD brings up video with what seems to be full resolution.  xrandr reports 1366x768.

Created attachment 505741 [details]
kernel messages with drm.debug=0x04, kms

Created attachment 505742 [details]
Xorg.0.log for kdm, i915.modeset=0

Created attachment 505743 [details]
Xorg.0.log for user, kms

This message is a notice that Fedora 15 is now at end of life. Fedora
has stopped maintaining and issuing updates for Fedora 15. It is
Fedora's policy to close all bug reports from releases that are no
longer maintained. At this time, all open bugs with a Fedora 'version'
of '15' have been closed as WONTFIX.

(Please note: Our normal process is to give advanced warning of this
occurring, but we forgot to do that. A thousand apologies.)

Package Maintainer: If you wish for this bug to remain open because you
plan to fix it in a currently maintained version, feel free to reopen
this bug and simply change the 'version' to a later Fedora version.

Bug Reporter: Thank you for reporting this issue and we are sorry that
we were unable to fix it before Fedora 15 reached end of life. If you
would still like to see this bug fixed and are able to reproduce it
against a later version of Fedora, you are encouraged to click on
"Clone This Bug" (top right of this page) and open it against that
version of Fedora.

Although we aim to fix as many bugs as possible during every release's
lifetime, sometimes those efforts are overtaken by events. Often a
more recent Fedora release includes newer upstream software that fixes
bugs or makes them obsolete.

The process we are following is described here:
http://fedoraproject.org/wiki/BugZappers/HouseKeeping