This request was evaluated by Red Hat Product Management for inclusion in a Red
Hat Enterprise Linux major release.  Product Management has requested further
review of this request by Red Hat Engineering, for potential inclusion in a Red
Hat Enterprise Linux Major release.  This request is not yet committed for
inclusion.

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 computer is not completely frozen when installation fails, stay in 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 above.

If the computer is completely useless after installation fails, you can also install Fedora with a VESA mode driver (see http://docs.fedoraproject.org/en-US/Fedora/13/html/Installation_Guide/
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.

Hello here are the promised logs from RHEL6_20100610

Hope it will help you. Again after moving to the console and then pressing ALT+F7 machine started to not respond.

Created attachment 424797 [details]
anaconda, yum, xrandr and xserver logs

Machine used in this case was not T400 but X60s (also with intel)

Created attachment 424947 [details]
anaconda.log from the tarball (attachment 424797 [details])

Created attachment 424948 [details]
dmesg.log from the tarball (attachment 424797 [details])

Created attachment 424949 [details]
ifcfg.log from the tarball (attachment 424797 [details])

Created attachment 424950 [details]
ks-script-9Autwz.log from the tarball (attachment 424797 [details])

Created attachment 424951 [details]
program.log from the tarball (attachment 424797 [details])

Created attachment 424952 [details]
storage.log from the tarball (attachment 424797 [details])

Created attachment 424954 [details]
X.log from the tarball (attachment 424797 [details])

Created attachment 424955 [details]
xrandr.log from the tarball (attachment 424797 [details])

I cannot help myself, but this

14:20:06,184 DEBUG   : X server has signalled a successful start.
14:20:06,192 INFO    : Started window manager, pid 692.
14:20:06,196 WARNING : '/usr/bin/metacity' specified as full path
14:20:06,746 DEBUG   : X server has signalled a successful start.
14:20:06,758 INFO    : Starting graphical installation.
14:20:07,412 INFO    : Detected 2016M of memory
14:20:07,412 INFO    : Swap attempt of 2016M to 4032M
14:20:07,542 WARNING : /usr/lib/python2.6/site-packages/report/accountmanager.py:153: SyntaxWarning: name 'HAVE_gnomekeyring' is used prior to global declaration
  global HAVE_gnomekeyring

doesn't look like Xorg issue (both X server and a window manager were apparently
run successfully).

Well, I can't see how that warning would prevent switching VTs.  But regardless, it's a report problem - not an anaconda problem.

I have logs (Xorg.log, ps aux, dmesg) from the "crashed" system. From the ps output is visible that the whole Xorg died and probably haven't do all necessary "cleanups" so switching back to vconsole is imposible.


The log is from RHEL6.0-20100620




Hope it will help you. The issue is 100% reproducible on my system.

Created attachment 425942 [details]
dmesg from crashed system

Created attachment 425943 [details]
Xorg.log from crashed system

Created attachment 425944 [details]
ps aux from crashed system

Can you ssh into the machine, start X from the ssh session, and reproduce the crash?  I suspect there's output on the X server's stderr that isn't making it into the X log.

Hi Adam,

unfortunately the problem with reproducing is following:

I'm able to reproduce the issue only by standard way. This means:

1) Boot latest RHEL 6.0 media (pxe or dvd-drive)
2) X will be started automatically
3) Ctrl + Alt + F1
4) Ctrl + Alt + F6

Expected results:

I'll be switched to X. Ctrl+Alt+F(n) switching will work.

Actual results:

Xorg process is not running anymore, system doesn't respond to input from keyboard


If I'll do it in following steps, the issue will not appear:

1) Boot latest RHEL 6.0 media (pxe or dvd-drive)
2) X will be started automatically
3) Ctrl + Alt + F1
4) ps -ef > /tmp/processes.txt (to see arguments given to Xorg and anaconda)
5) killall Xorg
6) anaconda will fall back to the text mode
7) Ctrl + Alt + F2 (or F3, I don't remember)
8) killall anaconda (anaconda will be killed, so I can start anaconda again)
9) execute anaconda with the same arguments as in /tmp/processes.txt
10) Xorg is started automatically


Expected results:

I'll be switched to X. Ctrl+Alt+F(n) switching will work.


Actual results == Expected results.


Hope it will help you.

I recommend you to grab T400 with the same hardware (lspci_t400.txt and Xorg.log) and test it by your own. The problem is that installation DVD has minimalist set of applications.

Created attachment 426483 [details]
lspci_t400

does booting with intel_iommu=off help?

Hello Dave,

intel_iommu=off is not helping. I ran to the same issue on RHEL6.0 20100629.

Hello I just tested newer nightly build and this problem just gone away on

xorg-x11-server 1.7.7.-17.el6 {x86_64,i686}


Feel free to re-open this issue if you'll find it on a current nightly build.