I just tried booting the F12 Beta live-cd on my system and I don't get further then the gdm login screen. The system freezes with the bottom panel only scrolled into the screen 50% although I can still move the mouse pointer. If I boot with the "nomodeset" parameter the freeze does not occur. The card is a Radeon 4850 with 1gb ram: (--) RADEON(0): Chipset: "ATI Radeon 4800 Series" (ChipID = 0x9442)
Can you try if following iso works : http://adamwill.fedorapeople.org/radeon-20091028-x86_64.iso
With this iso I don't even get to the gdm screen. I just get some nouveau messages and then the screen turns and stays black. Is it possible that Fedora is confused because of my on-board nvidia chip? I don't have a monitor connected to it but the nouveau messages during the kernel initialization make me suspicious.
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 anaconda crashes during the switching to the graphic mode, most likely the problem lies in Xorg support for your graphics chip. There are couple of options how we can obtain information necessary for resolving the 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 below. If the computer is completely useless after installation fails, you can also install Fedora with a VESA mode driver (see https://fedoraproject.org/wiki/Documentation_Beats_Installer 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.
Since this bugzilla report was filed, there have been several major updates in various components of the Xorg system, which may have resolved this issue. Users who have experienced this problem are encouraged to upgrade their system to the latest version of their packages (at least F12Beta, but even better if the very latest versions). Please, if you experience this problem on the up-to-date system, let us now in the comment for this bug, or whether the upgraded system works for you. If you won't be able to reply in one month, I will have to close this bug as INSUFFICIENT_DATA. Thank you. [This is a bulk message for all open Fedora Rawhide Xorg-related bugs. I'm adding myself to the CC list for each bug, so I'll see any comments you make after this and do my best to make sure every issue gets proper attention.]
Dennis please try with a live cd from : http://alt.fedoraproject.org/pub/alt/nightly-composes/desktop/ It should work now, we fixed a bunch of R600/R700 issue lately.
I tried to boot this iso twice. The first time I got a lot of garbage on the screen until gdm appeared. Then the machine froze before I could login. The second time I got a proper progress display but again a moment after the gdm screen appeared the system locked up.
(In reply to comment #6) > I tried to boot this iso twice. The first time I got a lot of garbage on the > screen until gdm appeared. Then the machine froze before I could login. > The second time I got a proper progress display but again a moment after the > gdm screen appeared the system locked up. You can try to boot in the text mode and then as normal user start program startx. Then if we are lucky, it would crash and you can collect the logs... /var/log/Xorg.0.log, output of the dmesg command. If you succeed please attach these as separate uncompressed attachments to this bug report. Thank you in advance.
I tried booting several times into runlevel 3 and i also removed the "quiet" and "rhgb" boot parameters but once the kernel initialization is complete the screen gets switched to a corrupt framebuffer and after that i can't do anything. I waited for a bit a tried to reboot blindly with ctrl+alt+del to see if it's just the display that is corrupted but the machine didn't respond. It seem the case where i managed to get plymouth to display properly was just luck.
Can you login through ssh on the computer after booting in runlevel 3 with KMS enabled ? Also add drm.debug=15 to your command line. Without full dmesg of KMS it will be hard to help debug your issue. How much RAM you have ?
The machine has 4gb ram. If I wait for a while I can ping the system and if I boot into runlevel 3 and wait for a while i can start X by blindly typing "root" and then calling startx. In that case I get a black screen with a pointer which I can move around for a moment but then the system freezes again. The problem is that the live-cd doesn't allow an external login using ssh (or at least i couldn't connect when i tried) and i cannot do much on the system itself because I can't see anything due to the messed up screen (unless i use the nomodeset option). Are there any alternative methods to get that data off the machine?
(In reply to comment #8) > I tried booting several times into runlevel 3 and i also removed the "quiet" > and "rhgb" boot parameters but once the kernel initialization is complete the > screen gets switched to a corrupt framebuffer and after that i can't do I think you were on the right track here. Get certainly rid of rhgb and quiet, add 3 to the end, but add also nomodeset. Will this combination boot up?
This bug appears to have been reported against 'rawhide' during the Fedora 12 development cycle. Changing version to '12'. More information and reason for this action is here: http://fedoraproject.org/wiki/BugZappers/HouseKeeping
I updated the live-cd to a nightly rawhide version (26.Dec) and still see the same problem. Adding "nomodeset" allows me to boot normally into the desktop (I'm posting this from such a session) although the display is painfully slow. The Xorg log says the radeon driver is used. I also noticed that using "nomodeset" the live-cd boots up a lot faster and when not using any boot options and waiting after the frozen gdm lockup for a minute my cpu fan speeds up indicating that the cpu is getting utilized heavily.
Created attachment 381035 [details] dmesg output after boot into runlevel 3 I managed to boot into runlevel 3 and blindly set a root pw, disable the firewall and start sshd so I could log into the system from another machine. After booting the system with "rhgb quiet" removed and "3 drm.debug=15" added I grabbed the dmesg log which you will find attached.
In case it helps debugging here is the smolt profile from F11 running live on the system: http://www.smolts.org/client/show/pub_d3abe799-fc48-4b2e-9366-9cf035a6e7b4
After some discussion on the testing mailinglist adding "nouveau.modeset=0" did the trick and the machine now boots into runlevels 3 and 5 with the displays native resolution of 1920x1200. Two things though: 1. During boot I just got the same progress bar at the bottom that I also get on F11. Aren't I supposed to see a funky boot plugin with KMS? 2. While the performance is not as unusable as it was with "nomodeset" It's still a lot worse compared to F11. I can barely play a youtube video. (eats one of my two cpu cores almost completely whereas on F11 that takes about 15% in "top") Looks like the real culprit is the nouveau driver here.
Thank you for updating the bug report. Jerome, I've switched back the Fedora version to 12 from rawhide as it happens with both. Let me know which version you want to track. -- Fedora Bugzappers volunteer triage team https://fedoraproject.org/wiki/BugZappers
F12 or Rawhide
Adding Dave and Ben in CC. Recap: on a computer with onboard nvidia and discrete ati/r700 graphics, KMS starts both nouveau and radeon, leading to unusable display even in runlevel 3. Disabling KMS/nouveau with nouveau.modeset=0 leads to a usable system in both runlevel 3 and 5, using KMS/radeon. -- Fedora Bugzappers volunteer triage team https://fedoraproject.org/wiki/BugZappers
Update: Using F14 alpha rc3 I can now boot to the desktop without any modifications to the boot option. However the graphical boot isn't displayed properly and instead I get to see some high resolution console output. Adding "nouveau.modeset=0" fixes this and I get a proper graphical boot. So it seems this has improved but still isn't really fixed.
If you're seeing a high resolution console correctly, nouveau has done its job. Plymouth is responsible for displaying the boot splash screen.
It's still possible that the modesetting isn't working properly in a way that the mode gets set ok visually but something else goes wrong and confuses plymouth.
This message is a reminder that Fedora 12 is nearing its end of life. Approximately 30 (thirty) days from now Fedora will stop maintaining and issuing updates for Fedora 12. 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 '12'. 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 12'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 12 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 12 changed to end-of-life (EOL) status on 2010-12-02. Fedora 12 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.