User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:126.96.36.199) Gecko/20090803 Fedora/3.5.2-2.fc11 Firefox/3.5.2
Trying the F12 Alpha liveCD, but it froze completely at start of X.
F11 works fine on same hardware.
Steps to Reproduce:
1.On my computer with i810 chip.
2.boot f12 alpha live CD
Freezes completely at start of X
Successful booting of graphical live user f12 system
Trying to get info for the bug report:
Digital photos of the screen during start up (kernelparameters QIET and RHGB removed). Photos attached.
Also F11 logfiles attached.
Trying to get logs of F12 startup:
I found some advice in bug #518300 which I have tried with my limited skills:
At the swithing to graphic mode I succeded once with (Ctrl-alt-F2) to switch to other terminal, but after a few seconds some text came up and then the screen turned black and completely frozen again, there were no time to collect logfiles.
Tried using the VESA mode driver "xdriver=vesa" at kernel line but not working. I also tried the f12 alpha DVD and then a simplified installer instead of the normal anaconda graphical installer came up, also when using "basic driver" option.
Booted the f12 live CD into text mode by adding a "3" at the end of kernel line, got into text mode and logged in successfully as "liveuser" but then doing "startx" resulted in black screen and complete freeze again.
I do not know what to try next to get boot log files from f12. Suggestions welcome!
Perhaps I could install a full F12 text mode system from the DVD, but I dont know A) how to shrink my F11 system currently occupying my hard discs (only 50% used, but the LVM is 100% of the space) and B) how to actually get the DVD- installation to be non-graphical.
If you have a place you can scp out to, you can get the log files when in text mode with scp location-of-logfile username@hostname:location.
Alternatively, if you can pull the contents up on the screen and take a picture with a digital camera, that might provide some insight.
Created attachment 358897 [details]
F11 anaconda.xlog same Hardware
If F11 logs are useful tell me and I will attach them. F11 works fine on this h/w.
Created attachment 358905 [details]
Photo of boot 1 raminfo
Created attachment 358907 [details]
Photo booting1 (f12 alpha live)
Created attachment 358908 [details]
Photo booting2 (f12 alpha live)
Created attachment 358910 [details]
Photo booting3 (f12 alpha live)
Created attachment 358911 [details]
Photo booting4 (f12 alpha live)
Created attachment 358912 [details]
Photo booting5 (f12 alpha live)
Created attachment 358913 [details]
Photo booting6 (f12 alpha live)
Created attachment 358914 [details]
Photo booting1a (f12 alpha live)
(In reply to comment #1)
> If you have a place you can scp out to, you can get the log files when in text
> mode with scp location-of-logfile username@hostname:location.
Are those log files useful if X has not attepted to start? Because after that everything freezes...
> Alternatively, if you can pull the contents up on the screen and take a picture
> with a digital camera, that might provide some insight.
I tried this. If photo info is missing and you think more photos can be of use let me know.
Created attachment 358973 [details]
Created attachment 359137 [details]
Up to date F11 logfile Xorg.0.log
I started F12 (11.91) liveCD in text mode (removed QUIET and RHGB from kernel line and added "3").
then logged in as "liveuser" and started X with "startx".
Before the screen goes black and freezes, for a second a X-info page came up on the screen. The last line of info that came up was that the logfile ~/var/log/Xorg.0.log was started.
looking at the F11 Xorg.0.log file I recognize the sequence from the F12 "1 second screen" so I guess that the crash happens after the "logfileline".
from the F11 Xorg log attachement:
(==) Log file: "/var/log/Xorg.0.log", Time: Sat Aug 29 11:02:57 2009
(II) Loader magic: 0x640
(II) Module ABI versions:
X.Org ANSI C Emulation: 0.4
X.Org Video Driver: 5.0
X.Org XInput driver : 4.0
X.Org Server Extension : 2.0
(II) Loader running on linux
(++) using VT number 1
(--) PCI:*(0@0:1:0) Intel Corporation 82810E DC-133 (CGC) Chipset Graphics Controller rev 3, Mem @ 0xf8000000/67108864, 0xf4000000/524288, BIOS @ 0x????????/131072
Created attachment 359713 [details]
Screenmessage just before screen goes black
This came up on the screen for a few seconds at the time for swiching to graphical mode and before the screen went black. The parameter "nomodeset" were added to the boot line.
Tried booting the "f12 snap1 live-version" (without changing any parameters) but the black screen freeze problem is still there.
Booting from the DVD and selecting
Install system with basic video driver
worked for me.
Created attachment 361072 [details]
The file: messages, from test-dayCD booting
With the test-day CD the booting succeded! In this file there are some automatic debugging that might be interesting. I think XAA acceleration is used in this test day version.
Created attachment 361073 [details]
The file: Xorg.o.log, from test-dayCD booting
At the login screen there were also a boot message "starting abrt deamon:failed to start:timeout waiting for child." Perhaps that is not relevant for this bug.
This issue does not happen anymore. So I think this bug should be closed. Can I do that, since I reported it?
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.]
(In reply to comment #21)
> This issue does not happen anymore. So I think this bug should be closed. Can I
> do that, since I reported it?
Yes, the reporter can close a bug at any time. I am currently performing some cleanup for mcepl anyway, so I will go ahead and set this to CLOSED WORKSFORME since the reporter states (in comment #21) that the issue no longer occurs. Thank you for your work on this bug.