User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.0.3) Gecko/2008092417 Firefox/3.0.3 (version selection in bugzilla has no "beta" or version 10; this bug is against the Fedora 10 Beta1 DVD install) Fedora boots from DVD and goes through all the confirmation successfully before starting the graphical frontend. At that point, it freezes the system completely and requires a hard reset or cold boot. I am trying this on a system with the Intel G45 chipset. Specifically, I am using an Intel DG45ID motherboard with HDMI output. Reproducible: Always Steps to Reproduce: 1.Boot through DVD and choose install (first option in menu) 2.Go through all confirmation on text frontend Actual Results: Screen goes dark completely, keyboard is completely frozen (control-alt-delete has no effect). As such, I cannot get any debugging output. Expected Results: Expect graphical install (Plymouth) to show up.
If I choose to use "text" mode at the boot menu, then I can get much further; but this also fails eventually...will log a seperate bug for that.
(In reply to comment #1) > If I choose to use "text" mode at the boot menu, then I can get much further; > but this also fails eventually...will log a seperate bug for that. How much further? If the install completes, but the system has the same black screen symptoms on the first boot attempt this is most likely an X bug.
I can confirm these symptoms with the DG45ID motherboard. In my case output is DVI not HDMI. I don't think that it locks up, I think X fails. (The screen is just black) Installing proceeds: * Look for install image on CD /dev/sr0 (succeeds) * Local Installation Media Detected (succeeds) * Anaconda 11.4.1.40 begins .... then black screen and nothing I posted another bug for installing to this motherboard with F10 alpha ... the install succeeded but on boot this is what the monitor looks like http://www.flickr.com/photos/9657786@N06/2906533947/ Also, Phoronix reports that Ubuntu 8.10 alpha 3 will install with this chipset http://www.phoronix.com/scan.php?page=article&item=intel_x4500hd&num=1
Philip - your screenshot is probably a symptom of firstboot and plymouth not getting along. What happens if you press a key, try switching VTs, or something like that? As for the original bug, what happens if you add xdriver=vesa to the boot options. Perhaps this is an X problem, but specific to your hardware's video driver. The generic one might work better.
(In reply to comment #2) > (In reply to comment #1) > > If I choose to use "text" mode at the boot menu, then I can get much further; > > but this also fails eventually...will log a seperate bug for that. > > How much further? If the install completes, but the system has the same black > screen symptoms on the first boot attempt this is most likely an X bug. See Bug 465127, which my bug is Dup (465206) to.
It's not true that the install proceeds anyway after the screen goes black because I'd be seeing activity lights from the DVD drive with all the reads/copies that should be happening. Switching VT, etc, etc don't work. The only solution I've found to get access back is to press the reset button.
(In reply to comment #2) > > Also, Phoronix reports that Ubuntu 8.10 alpha 3 will install with this chipset > > http://www.phoronix.com/scan.php?page=article&item=intel_x4500hd&num=1 I am not sure how much we should buy into this because the Phoronix folks don't detail all the workarounds they have taken to get it installed. I've actually tried Ubunutu 8.10 alphas 4, 5, and 6. The only consistent way to get it them installed successfully is through text mode. After installation, it's a by your luck hope to see if X will start successfully on its own. I've really only been able to get it to start without any intervention once, with alpha6. All of the others require that I turn the "NoAccel" option to true in xorg.conf for the intel driver. Ubuntu is using version 2.4.1 of the Intel driver. What is Fedora 10B1 using? I'll try the xdriver=vesa tonight. It sounds promising based on my experience with the Ubuntu images.
I have similar symptoms with anaconda version 11.4.1.40 on x86_64 and ATI R300 (Radeon 9500 Pro) graphics card. I am left with a black screen and a nonresponsive keyboard so there is no chance to look at any logs. Adding 'nomodeset' allows to get over this hurdle. If I am trying "rescue" or an installation in a text mode, without using 'nomodeset', then for a short moment my monitor blinks "Out of range" message and I can proceed after a short while (with a font visibly smaller than a default one). If there is an insistence of keeping a graphics mode setting in kernel, which apparently crashes machines left and right, then maybe at least in a default boot menu there could be an entry with a 'nomodeset' parameter already added?
Here's the latest updates on my side: 1. Setting xdriver=vesa seems to allow me to proceed, i.e. anaconda is starting the graphical install interface, but I still get a blank screen. However, I can now switch VT and finds out that X is trying to run the install at resolution of 800x600. For some reason, my 1080P display connected via HDMI is drawing a blank; nothing is displayed at all! Is there a way to specify a custom resolution for X when specifying the xdriver? 2. Disabling modeset doesn't improve the situation with either the default or vesa xdriver
Yes, you can also use resolution=.
(In reply to comment #10) > Yes, you can also use resolution=. Unfortunately, I tried 1920x1080 and 1280x720...and neither of these are valid modes for the vesa driver. As such, I am still getting a blank screen. At this point, this release is pretty much a wash for me as the e1000 driver is disabled, so text mode install crashes. And because of this problem with the intel driver, I can't get graphical mode to start.
I'm also seeing this on an HP DL380G5 with an ATI ES1000 graphics chip. The 'xdriver=vesa' workaround was successful for me up until I hit another bug where hal can't see any cciss devices to partition (Bug #466181). I've found that the system isn't actually locked right away, it's actually shutting down which takes about 5 seconds on my system. I determined this by doing a Ctrl-Alt-F2 followed by Alt-F6 just in time to see that it was now safe to restart my system.
I am seeing the same problem on a Lenovo T400 laptop with the Intel GM45 chipset, using the integrated Intel X4500 graphics. Using the standard install method with no extra boot options, I just get a blank screen after starting the GUI. If I use the xdriver=vesa option, I get a corrupted display. If I try to install in text mode, I get much farther but eventually get an exception from anaconda.
Same problem here running fedora rawhide (upgraded from fedora 9) on Sony Vaio VGN-SR11M (Intel x4500hd), only with Driver "vesa" I get the LVDS working. there are two already open bugs on: https://bugs.freedesktop.org/show_bug.cgi?id=17292 https://bugs.freedesktop.org/show_bug.cgi?id=17508
There have been bunch of bug fixes Could you retest with the latest kernel ( -132 at the time of this writing ) You can get the latest kernel build here http://koji.fedoraproject.org/koji/buildinfo?buildID=72270 And with the latest xorg-x11-drv-ati. ( -60 at the time of this writing ) You can get the latest xorg-x11-drv-ati build here http://koji.fedoraproject.org/koji/packageinfo?packageID=95 And report back if it either improves or fixes this issue.. Thanks.
As of F10/Cambridge release, the G45 chip in the DG45ID board works automagically. Live view and full install work fine.
Re comment #15: to check what happens while installing installation images using those kernels and drivers would be needed so this will have to wait. With installation images from F10 release, i.e. kernel-2.6.27.5-117, my hardware (ATI R300 - Radeon 9500 Pro) does not lock up without "nomodeset" anymore but the moment X server is starting text consoles are becoming black-on-black. They are not locked up, as Alt-Ctrl-Del for example will reboot a machine "in blind", but not that usable if one would need something there. Also a monitor makes frequent clicking noises and in general is not very happy. All of the above happens even when xdriver=vesa is used. These problems vanish when "nomodeset" is applied. Text consoles turn into black-on-black, and a monitor is noisy, in a normal usage too if I will skip "nomodeset". Will check new builds with rawhide later.
Reporter, could you please reply to the previous question? If you won't reply in one month, I will have to close this bug as INSUFFICIENT_DATA. Thank you.
Good evening, I think i've got the same problem : Anaconda freeze but not at the same time, just two screens after the beginning. In fact it freezes just when I choose the keyboard (French-latin9) and click on the 'Next' button, Anaconda freeze. I've tried to install Fedora 10 in text mode but the installation freezes at the same time. I've downloaded teh Fedora 9 and another Fedora 10 (from another mirror) but each time it's the same problem. So i can't upgrade my PC. Thanks for your help.
I have been seeing the black screen issue with rawhide network installs. Both of the machines I tried installing had Nvidia cards, and anaconda worked correctly (albeit non-interactively, as per my kickstart) in graphical mode after specifying "xdriver=vesa" at the kernel command line.
This message is a reminder that Fedora 9 is nearing its end of life. Approximately 30 (thirty) days from now Fedora will stop maintaining and issuing updates for Fedora 9. It is Fedora's policy to close all bug reports from releases that are no longer maintained. At that time this bug will be closed as WONTFIX if it remains open with a Fedora 'version' of '9'. Package Maintainer: If you wish for this bug to remain open because you plan to fix it in a currently maintained version, simply change the 'version' to a later Fedora version prior to Fedora 9's end of life. Bug Reporter: Thank you for reporting this issue and we are sorry that we may not be able to fix it before Fedora 9 is 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 please change the 'version' of this bug to the applicable version. If you are unable to change the version, please add a comment here and someone will do it for you. 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
Fedora 9 changed to end-of-life (EOL) status on 2009-07-10. Fedora 9 is no longer maintained, which means that it will not receive any further security or bug fix updates. As a result we are closing this bug. If you can reproduce this bug against a currently maintained version of Fedora please feel free to reopen this bug against that version. Thank you for reporting this bug and we are sorry it could not be fixed.