Hide Forgot
Description of problem: On start-up, after the kernel loads the screen freezes, showing my (garbled) shutdown screen from my concluding f14 session and leaves me with no keyboard or other controls. Version-Release number of selected component (if applicable): can't tell since I can't get a start-up on the WM How reproducible: very, with both the f15 beta live AND the gnome --shell live (which I know is fedora based but I would expect the f15 live to be more up-to-date) Steps to Reproduce: 1.Downloaded f15 beta live x86-64 from fedora torrent link. Installed to USB with Unetbootin. 2.Startup, choosing verify and run, kernel loads fine, but once into the shell, fail 3. no keyboard, (therefore no runlevel to drop to) or mouse (of course) no controls, just the garbled screen from my previous shutdown on f14 (which is running the old version of gnome shell --from the repos-- without problems) Actual results: absolutely no joy Expected results: Additional info:
Thanks for the bug report. The problem you have described is not (and can not be) related to gnome-shell (it only starts after login). it's probably a display driver bug. Moving from gnome-shell to xorg-x11-drivers. There is some additional information we require that will be helpful in our diagnosis of this issue. Please add drm.debug=0x04 to the kernel command line, restart computer, and attach * your X server config file (/etc/X11/xorg.conf, if available), * X server log file (/var/log/Xorg.*.log) * output of the dmesg command, 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. -- Fedora Bugzappers volunteer triage team https://fedoraproject.org/wiki/BugZappers
Created attachment 496809 [details] Xorg.0.log
Created attachment 496810 [details] xorg.conf
Created attachment 496812 [details] /var/log/messages
Created attachment 496813 [details] dmesg
here you go, have fun, I'll be keeping my eye on this since I do want to be working with gnome 3 (no matter the controversy) and fed15,
We need the logs from F15, not F14 (in your case, from the livecd that fails). -- Fedora Bugzappers volunteer triage team https://fedoraproject.org/wiki/BugZappers
OOOOh. Well, maybe it wasn't clear in the description, this does not allow the use of the keyboard or, obviously, the mouse. This stops me from getting to a lower run level to get to the logs, etc. Unless you have another solution? I will try to add the drm.debug line to the kernel line on f15, but ... well i will try.
Ctrl+Alt+F2 doesn't work? -- Fedora Bugzappers volunteer triage team https://fedoraproject.org/wiki/BugZappers
No, there is no keyboard. I just tried it again and no joy, exactly the same jumbled mess. Does it not strike you as seriously weird/wrong that it is picking up my f14 desktop to jumble up, not the f15 desktop? In fact, if there are any applications running on the desktop at shutdown (as there was when I rebooted out of Unetbootin) it still is showing pieces of that as well.
Sounds like a video memory corruption. I have no idea how can you debug such thing, I'll try to find out. -- Fedora Bugzappers volunteer triage team https://fedoraproject.org/wiki/BugZappers
(In reply to comment #3) > Created attachment 496810 [details] > xorg.conf Section "Device" Identifier "Videocard0" Driver "nvidia" EndSection ---- With this xorg.conf it is no surprise F15 doesn't work. Please, remove this xorg.conf completely, and try again.
(In reply to comment #12) > With this xorg.conf it is no surprise F15 doesn't work. Please, remove this > xorg.conf completely, and try again. I might have mis-read, but he tried F15 on a live cd, not on an installed system, so it shouldn't have read that configuration file at all. -- Fedora Bugzappers volunteer triage team https://fedoraproject.org/wiki/BugZappers
In reply to the comments above: " With this xorg.conf ..." I did not set up this xorg.conf file, it was auto generated when I installed the akmods package for my nVidia card. I am at my work machine which is a different processor, but with another nVidia card and have the same xorg.conf file, so... i am guessing that it is the standard file for xorg and not something kludgy as you intimate. "tried F15 on a live cd" you are correct, I used a USB drive with Unetbootin to set up the .iso for install. I have an existing instance of f14 and it appears that this is being accessed during start-up for some unknown reason. Let me add, further, that there are two different kernel loading notifiers (like a little graphics doodley) one being for the standard non-modified kernel which uses an icon with the "f/ infinity" symbol that gradually changes to white: this is what appears when I boot from the live cd version. The other, which is a multicolored three bar (left to right) thingy that has a "fedora 14" on the right which changes to white when the kernel is loaded and comes with the nVidia mod kernel. In this way I can be clear which kernel is loading. Somehow the f15 kernel is accessing the the f14 desktop. and failing.
(In reply to comment #14) > In reply to the comments above: " With this xorg.conf ..." > I did not set up this xorg.conf file, it was auto generated when I installed > the akmods package for my nVidia card. I am at my work machine which is a > different processor, but with another nVidia card and have the same xorg.conf > file, so... i am guessing that it is the standard file for xorg and not > something kludgy as you intimate. Except that nvidia binary driver is from rmpfusion.org (and indirectly from the nvidia inc.), not from Fedora. We are sorry that we cannot help you with your problem, but we are not able to support binary-only drivers. If you would be able to reproduce this issue using only open source software, please, reopen this bug with the additional information, but in meantime I have no choice than to close this bug as CANTFIX (because we really cannot fix it). The open source 'nouveau' driver (in package xorg-x11-drv-nouveau) is the recommended alternative for users of Nvidia graphic chips. It is used by default in Fedora 11 and later if you remove any customizations that explicitly set the video driver. The older "nv" driver may be needed in some cases. It is also available in older Fedora releases. Install the packages xorg-x11-drv-nouveau or xorg-x11-drv-nv and override the X server's default choice if necessary. See https://fedoraproject.org/wiki/Features/NouveauAsDefault for more information. If you used a non-packaged version of the driver from the Nvidia website please clean your system from additional libraries and software it installed. For users who are experiencing problems installing, configuring, or using the unsupported 3rd party proprietary "nvidia" video driver, Nvidia provides indirect customer support via an online web based support forum. Nvidia monitors these web forums for commonly reported problems and passes them on to Nvidia engineers for investigation. Once they've isolated a particular problem, it is often fixed in a future video driver update. The NVNews Nvidia Linux driver forum is located at: http://www.nvnews.net/vbulletin/forumdisplay.php?s=&forumid=14 Once you have reported this issue in the Nvidia web forums, others who may have experienced the particular problem may be able to assist. If there is a real bug occuring, Nvidia will be able to determine this, and will likely resolve the issue in a future driver update for the operating system releases that they officially support. While we does not support the proprietary nvidia driver, users requiring technical support may also find the various X.Org, XFree86, and Red Hat/Fedora mailing lists helpful in finding assistance: X.Org mailing lists: http://www.freedesktop.org/XOrg/XorgMailingLists XFree86 mailing lists: http://www.xfree86.org/sos/lists.html Red Hat/Fedora mailing lists: https://listman.redhat.com/mailman/listinfo
EXCUSE ME! please re-read the problem, at no time am I talking about my current setup that does use the binary nVidia driver, I am talking about the f15 live disk that I installed on a USB drive. If that drive is trying to use the nVidia driver then YOU do have a problem with it. I am sorry to shout, but I am kind of POed that you didn't read TFB and recognize the issue, but you think that you should close the bug. Who are you to make a move like this when you are clearly not paying attention to the actual issue. Forgive me if there is something I am missing, but it seems quite straightforward that it does not and has never involved the nVidia drivers UNLESS there is a problem with the live CD. Please reopen the bug and try to fix it.
(In reply to comment #16) > Forgive me if there is something I am missing, but it seems quite > straightforward that it does not and has never involved the nVidia drivers > UNLESS there is a problem with the live CD. Except log from running with the nvidia driver (attachment 496809 [details]) is the only Xorg.0.log I have. Then I have /var/log/messages (attachment 496812 [details]), which reads: May 3 13:14:36 dhcfed kernel: [ 9.287290] nvidia: module license 'NVIDIA' taints kernel. and dmesg (attachment 496813 [details]) with [ 9.656669] nvidia: module license 'NVIDIA' taints kernel. Then I have asked you in the comment 12 Please, remove this xorg.conf completely, and try again. then I have explained in the comment 15 that whole akmod-nvidia stuff is [...] nvidia binary driver is from rmpfusion.org (and indirectly from the nvidia inc.), not from Fedora. so it has nothing to do with us. So, if you want this bug to be reopened, please, remove (at least momentarily) nvidia driver (inclduing /etc/X11/xorg.conf), make sure that your Xorg installation is not corrupted by the driver (rpm -Va xorg\* should be enough), and post here those logs again. Thank you for helping to make Fedora better
Matej mis-understood you. Please attach the logs from the livecd itself, not from the installed system. -- Fedora Bugzappers volunteer triage team https://fedoraproject.org/wiki/BugZappers
(In reply to comment #16) > I am talking about the f15 live disk that I installed on a USB drive. OK, rereading this and I am obviously an idiot. I am sorry (generally the rule of thumb is that issue with one videodriver has not much common with another video drivers, so information about nvidia chipset ... whatever driver you use ... is usually not helpful for issue with vmware, but it isn't an excuse for me). So, let’s go back to make it clear what's actually going on. The only relevant part from the comment 17 is that we still don't have any information to work on (because only information we have is from nvidia driver). So, we need to get that information somehow. 1) If Xorg locks up when running in the default mode (which seems to be your case), we need to get to the system somehow. 2) You can try to start in the text mode in runlevel 3. Please press [TAB] in the introductory menu to get to the kernel command line and there (of course without quotes) * remove from the line "rhgb quiet" (if it is there at all) * add "drm.debug=0x04 3" Then proceed with the boot. You should get to the terminal display, where you could log as user liveuser and with empty password. Then run startx to get Xorg (you can stop it with Ctrl-Alt-Backspace if it surprisingly doesn't crash on its own). Hopefully, this time (if it crashes) you should get back to the console and there you could collect both output of dmesg command and /var/log/Xorg.0.log. Getting these logs attached to this bug would be certainly very helpful. For normal use you can try using "Basic video driver" option from the initial startup menu. You won't get gnome-shell (only fallback mode), but it could be usable as well. I am sorry again for the misunderstanding I caused and thank you for any assistance you can get us.
Created attachment 498013 [details] second dmesg (f15)
Created attachment 498014 [details] second X0rg.log (f15)
We need the logs from running with the normal driver (not basic video). Matej's explanation on how to get the logs is detailed enough.
(In reply to comment #23) > We need the logs from running with the normal driver (not basic video). Matej's > explanation on how to get the logs is detailed enough. Yes, sorry xdriver=vesa nomodeset shouldn't be on the kernel command line at all
I'm sorry, I'm really not retarded but last night I was sick while I was trying to do this. I typed up an explanation of what I did and how I got to where I was, but the comments box (where I am now) kept self-propagating with a copy of an old message (see above where the old message was plugged in) and I was just too tired to rewrite the whole gory scene. First I tried to run using "default", deleted "quiet rhgb" (please note the reversed syntax and the addition of an extra space, all part of the kernel line in every situation mentioned below) and added "drm.debug=0x04 3" to the end of the kernel line. Would not complete kernel loading, tried with the deleted line left in and got a kernel panic before it was two seconds into the kernel start. After those attempts I tried the second entry in the menu which was the f15 live and this loaded once to where I could log into run level (3 or 4 i am guessing) as liveuser, but then it crashed on startx and locked up: hard reboot The second time I tried the second entry it would not boot the kernel entirely but hung at an intermediate point that gave a garbled screen as well. One other time I tried to click through the menu and start with the first hard disk (SDA) and it also failed on that, giving nothing but a garbled screen. (Note, the first time I ran this I ran it on "verify and run" and had no warnings or failures, it just didn't load past the kernel (past the X attempt). It was at this point that I tried the basic video mode which did finally let me in to the login and, by elevating to su I ran startx and got, finally, into the desktop. from which I scooped up what I attached. What I am going to do now, however, is to reDL the damn iso and try that, because this strikes me as just too ornery for all the work we are putting in to it: you guys especially. Also, I don't like it that things are changing, one time it does one thing and another time something else. This sounds like such an obvious flaw that I find it hard to accept it would have made it this far in testing. So the only logical reason (or the most reasonable explanation) is a flaw in the iso on my end. I'll post back here when I try that to let you know if that was the real culprit. BTW: I said in the deleted notes from last night and want to make sure you know that I appreciate your apology yesterday. I was ready to givce up on it last night, but kept at it only because you were kind enough to apologize. Thank you.
OK, sorry to take so long, but i've been rather sick for a few days. Managed to get the wife out of the house so I could work on this without her fussing at me for messing with the computer when I should be in bed. Cut to the chase: it was not a corrupted download. I got exactly the same problems as I have detailed above including all the variants of fail mentioned above. I could get in to the run levels 3 & 4 but could not run startx successfully from there which means that you would not get an xorg file i think? anyway, i was not able to do very much before I spazzed something like running vim and not being able to do anything in it since I had no keyboard in vim. makes it hard to do very much in terms of saving files for you when I can't get into anything that can hold the files for saving because it won't recognize anything. If you have a suggestion of course I will be glad to try. Over to you guys again.
OK, so the conclusion is that we are running only in the basic mode (which is VESA compatibility mode without any 3G graphic at all), right? That's probably all we can do in this triage stage. Passing the bug to developers and hoping for the better. Thank you very and thank you very much for your patience with me (and I hope you'll get better)
OK, Thanks for your attempt to solve, I do hope the devs figure it out and get it fixed for the coming launch, this is the first time I haven't been able to install the beta in years, so i hope it all works out.
Final solution: something in the final packaging for f15 fixed the problem. New download of the release gave no problems, all machines are running fine and I am a happy camper. Thanks to all of you that gave your time to help
Closing then. -- Fedora Bugzappers volunteer triage team https://fedoraproject.org/wiki/BugZappers