Bug 986620 - Multiple fedora 19 installation boot methods fail to display anaconda
Multiple fedora 19 installation boot methods fail to display anaconda
Status: CLOSED EOL
Product: Fedora
Classification: Fedora
Component: xorg-x11 (Show other bugs)
19
Unspecified Unspecified
unspecified Severity unspecified
: ---
: ---
Assigned To: X/OpenGL Maintenance List
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2013-07-20 22:43 EDT by Mark Patton
Modified: 2015-02-17 11:16 EST (History)
9 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2015-02-17 11:16:49 EST
Type: Bug
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)
Result of running lspci.txt (6.45 KB, text/plain)
2013-07-20 22:43 EDT, Mark Patton
no flags Details
/var/log/messages (99.21 KB, application/gzip)
2013-07-21 13:53 EDT, Mark Patton
no flags Details
X11 log (10.40 KB, application/gzip)
2013-07-21 13:54 EDT, Mark Patton
no flags Details
messages (uncompressed) (584.54 KB, text/plain)
2013-07-21 14:43 EDT, Steve Tyler
no flags Details
Xorg.0.log (uncompressed) (81.03 KB, text/plain)
2013-07-21 14:44 EDT, Steve Tyler
no flags Details
anaconda syslog (141.57 KB, text/plain)
2013-07-21 19:07 EDT, Mark Patton
no flags Details
anaconda X11 log (73.63 KB, text/plain)
2013-07-21 19:08 EDT, Mark Patton
no flags Details

  None (edit)
Description Mark Patton 2013-07-20 22:43:34 EDT
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.
Comment 1 Steve Tyler 2013-07-20 23:23:13 EDT
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?
Comment 2 Steve Tyler 2013-07-20 23:36:28 EDT
(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.
Comment 3 Steve Tyler 2013-07-21 01:01:13 EDT
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.
Comment 4 Mark Patton 2013-07-21 13:52:45 EDT
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.
Comment 5 Mark Patton 2013-07-21 13:53:31 EDT
Created attachment 776533 [details]
/var/log/messages
Comment 6 Mark Patton 2013-07-21 13:54:13 EDT
Created attachment 776534 [details]
X11 log
Comment 7 Steve Tyler 2013-07-21 14:28:09 EDT
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
...
Comment 8 Steve Tyler 2013-07-21 14:40:22 EDT
(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.
Comment 9 Steve Tyler 2013-07-21 14:43:45 EDT
Created attachment 776536 [details]
messages (uncompressed)

Uncompressed, text/plain files are easier to open in a web browser.
Comment 10 Steve Tyler 2013-07-21 14:44:28 EDT
Created attachment 776537 [details]
Xorg.0.log (uncompressed)
Comment 11 Steve Tyler 2013-07-21 15:20:24 EDT
With the install kernel (3.9.5-301), there were two kernel Call Traces:
$ egrep 'Command line:|Call Trace:' messages
Comment 12 Mark Patton 2013-07-21 19:07:41 EDT
Created attachment 776578 [details]
anaconda syslog
Comment 13 Mark Patton 2013-07-21 19:08:32 EDT
Created attachment 776579 [details]
anaconda X11 log
Comment 14 Mark Patton 2013-07-21 19:48:26 EDT
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.
Comment 15 Steve Tyler 2013-07-21 21:59:50 EDT
(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)?
Comment 16 Steve Tyler 2013-07-21 22:13:20 EDT
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 ...
Comment 17 David Shea 2013-08-08 10:11:25 EDT
Reassigning since this appears to be an issue with Xorg
Comment 18 Mark Patton 2013-08-13 21:55:07 EDT
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 ...
Comment 19 Fedora End Of Life 2015-01-09 14:01:37 EST
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.
Comment 20 Fedora End Of Life 2015-02-17 11:16:49 EST
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.

Note You need to log in before you can comment on or make changes to this bug.