Bug 986620
Summary: | Multiple fedora 19 installation boot methods fail to display anaconda | ||||||||||||||||||
---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
Product: | [Fedora] Fedora | Reporter: | Mark Patton <mpatton> | ||||||||||||||||
Component: | xorg-x11 | Assignee: | X/OpenGL Maintenance List <xgl-maint> | ||||||||||||||||
Status: | CLOSED EOL | QA Contact: | |||||||||||||||||
Severity: | unspecified | Docs Contact: | |||||||||||||||||
Priority: | unspecified | ||||||||||||||||||
Version: | 19 | CC: | anaconda-maint-list, dshea, g.kaviyarasu, jonathan, mkolman, mpatton, sbueno, stephent98, vanmeeuwen+fedora | ||||||||||||||||
Target Milestone: | --- | ||||||||||||||||||
Target Release: | --- | ||||||||||||||||||
Hardware: | Unspecified | ||||||||||||||||||
OS: | Unspecified | ||||||||||||||||||
Whiteboard: | |||||||||||||||||||
Fixed In Version: | Doc Type: | Bug Fix | |||||||||||||||||
Doc Text: | Story Points: | --- | |||||||||||||||||
Clone Of: | Environment: | ||||||||||||||||||
Last Closed: | 2015-02-17 16:16:49 UTC | Type: | Bug | ||||||||||||||||
Regression: | --- | Mount Type: | --- | ||||||||||||||||
Documentation: | --- | CRM: | |||||||||||||||||
Verified Versions: | Category: | --- | |||||||||||||||||
oVirt Team: | --- | RHEL 7.3 requirements from Atomic Host: | |||||||||||||||||
Cloudforms Team: | --- | Target Upstream Version: | |||||||||||||||||
Embargoed: | |||||||||||||||||||
Attachments: |
|
Did you try "Install Fedora 19 in basic graphics mode" under the Troubleshooting menu on the DVD? Also, could you confirm that your DVD passes the media test? (In reply to Mark Patton from comment #0) ... > And if I boot with "linux text" (off of the dvd), I get nothing at all just > a blank screen. I can't switch virtual terminals. ... To start the installer in text mode from the DVD: 1. At the grub2 "Install Fedora 19" menu item, press Tab. 2. Backspace over "quiet". 3. Type "text". 4. Press Enter. Xorg and metacity should be running too. If there are any logs in /tmp, could you attach them? X.log and syslog might be the most informative for this. dmesg output too. Success! I tried basic graphics mode under troubleshooting and was able to install. I had assumed that "linux text" was equivalent so hadn't bothered earlier. The machine seems to be running fine. The graphics work. I had some flakiness with restart crashing after installation and requiring a manual reset, but now things seem ok. Let me know if there's any other information you would like. I've attached the X log and syslog as requested, but these are from the installed system, not from during installation. I'm a little surprised that the graphics would work now, but not during installation when presumably the same X was running. Created attachment 776533 [details]
/var/log/messages
Created attachment 776534 [details]
X11 log
Congratulations and thanks for attaching the logs. This is more likely an X bug, but I will defer to the developers on that. The logs from the install are in /var/log/anaconda/. FYI, you are booting with "nomodeset" on the kernel command-line.[1] AFAIK, that doesn't have much effect once the system is booted. It would be useful though, if you could do a test boot after removing it. You can do that from the grub2 menu by pressing 'e' at the menu item you want to boot, removing "nomodeset" from the "linux" line, and pressing F10 to boot. Removing the "rhgb" and "quiet" options, too, will let you see the boot messages. [1] Snippet from attached /var/log/messages: ... Jul 21 05:09:37 localhost kernel: [ 0.000000] Command line: BOOT_IMAGE=/vmlinuz-3.9.5-301.fc19.x86_64 root=/dev/sda4 ro rootflags=subvol=root nomodeset rd.md=0 rd.lvm=0 rd.dm=0 vconsole.keymap=us rd.luks=0 vconsole.font=latarcyrheb-sun16 rhgb quiet ... (In reply to Mark Patton from comment #4) ... > The machine seems to be running fine. The graphics work. I had some > flakiness with restart crashing after installation and requiring a manual > reset, but now things seem ok. ... If you can reproduce that, please open a new bug. Sometimes abrt catches crashes, but there is no notification. You can launch abrt from Show Applications by typing "abrt" in the search box. Check the "All problems" checkbox to see crashes that require root permission. Created attachment 776536 [details]
messages (uncompressed)
Uncompressed, text/plain files are easier to open in a web browser.
Created attachment 776537 [details]
Xorg.0.log (uncompressed)
With the install kernel (3.9.5-301), there were two kernel Call Traces: $ egrep 'Command line:|Call Trace:' messages Created attachment 776578 [details]
anaconda syslog
Created attachment 776579 [details]
anaconda X11 log
Rebooting and setting the kernel parameters as requested resulted in a distorted screen. I could not switch virtual terminals. Also, after rebooting again, all my jab devices are failing. Good thing I found a ps2 keyboard. I will open a new bug when I have time. (In reply to Mark Patton from comment #14) > Rebooting and setting the kernel parameters as requested resulted in a > distorted screen. I could not switch virtual terminals. Thanks, Mark. That sounds like a graphics problem. The appropriate component is probably xorg-x11-drv-intel. You can change the component yourself or wait for an anaconda developer to triage this bug. > Also, after rebooting again, all my jab devices are failing. Good thing I > found a ps2 keyboard. I will open a new bug when I have time. If by "jab", you meant "usb", then that squares with the kernel call traces in your attachments: Snippet from attached /var/log/messages: ... Jul 21 05:11:40 localhost kernel: [ 2.760253] Call Trace: Jul 21 05:11:40 localhost kernel: [ 2.760256] [<ffffffff8146426b>] usb_suspend_both+0x9b/0x1d0 ... But they were with kernel 3.9.5-301. Did that happen with your newest kernel (3.9.9-302)? You may not need to open a new bug. The call trace here looks almost identical, although the kernel is 3.9.6-200.fc18.x86_64: Bug 983761 - [abrt] BUG: unable to handle kernel NULL pointer dereference at (null) Attaching your /var/log/messages would suffice ... Reassigning since this appears to be an issue with Xorg Steve, Sorry for not responding sooner. I haven't been able to reliably recreate the usb issues, but they have something to do with having a usb 3.0 blu-ray writer plugged in. Interestingly enough I also have a kinesis keyboard. If I'm able to get a repeatable failure, I'll open up a new bug report about it and attach the kernel messages. (In reply to Steve Tyler from comment #16) > You may not need to open a new bug. The call trace here looks almost > identical, although the kernel is 3.9.6-200.fc18.x86_64: > > Bug 983761 - [abrt] BUG: unable to handle kernel NULL pointer dereference at > (null) > > Attaching your /var/log/messages would suffice ... This message is a notice that Fedora 19 is now at end of life. Fedora has stopped maintaining and issuing updates for Fedora 19. It is Fedora's policy to close all bug reports from releases that are no longer maintained. Approximately 4 (four) weeks from now this bug will be closed as EOL if it remains open with a Fedora 'version' of '19'. 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. Thank you for reporting this issue and we are sorry that we were not able to fix it before Fedora 19 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, you are encouraged change the 'version' to a later Fedora version prior this bug is closed as described in the policy above. 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. Fedora 19 changed to end-of-life (EOL) status on 2015-01-06. Fedora 19 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. If you are unable to reopen this bug, please file a new report against the current release. If you experience problems, please add a comment to this bug. Thank you for reporting this bug and we are sorry it could not be fixed. |
Created attachment 776344 [details] Result of running lspci.txt Description of problem: Multiple installation methods all result in a blank screen after boot. The graphical install methods lets me switch to virtual terminals. If I check the shell I can see anaconda running with ps. When I go the F7 terminal, I just get a blank screen. And if I boot with "linux text" (off of the dvd), I get nothing at all just a blank screen. I can't switch virtual terminals. If I try a live usb, I just get a momentary distorted screen on boot and then just a blank screen. Version-Release number of selected component (if applicable): Fedora 19. How reproducible: Every time. Steps to Reproduce: 1. Pick a boot method. 2. Boot. Actual results: Failure. Expected results: Anaconda running in graphical or text mode. Additional info: I have been running redhat linux in various incarnations for almost 20 years now. I have never seen such a complete and utter failure. And this is hardware is only a year or two old! Amazing! Note that this is running Fedora 17 without trouble. I've attached the result of running lspci -v. I have also experience similar failures to this attempting to install Fedora 19 on multiple other machines. All only a couple years old.