Bug 586122 - When launching a kickstart install, fails to launch X and falls back to text mode
Summary: When launching a kickstart install, fails to launch X and falls back to text ...
Status: CLOSED DUPLICATE of bug 579654
Alias: None
Product: Red Hat Enterprise Linux 6
Classification: Red Hat
Component: anaconda
Version: 6.0
Hardware: All
OS: Linux
Target Milestone: rc
: ---
Assignee: Anaconda Maintenance Team
QA Contact: Release Test Team
Depends On:
TreeView+ depends on / blocked
Reported: 2010-04-26 20:36 UTC by Joshua Kwan
Modified: 2010-04-26 20:41 UTC (History)
0 users

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
Last Closed: 2010-04-26 20:40:22 UTC
Target Upstream Version:

Attachments (Terms of Use)

Description Joshua Kwan 2010-04-26 20:36:23 UTC
Description of problem:
When I launch a kickstart install, it always uses text mode and anaconda.log reports that X has failed to start even though it has started (in fact, to see the details of the install in text mode, you have to switch back to VT1.)

Version-Release number of selected component (if applicable):
whatever came with RHEL 6.0 Beta 1

How reproducible:

Steps to Reproduce:
Just boot the RHEL 6 DVD (remastered so that kickstart file is on the disc, and kernel command line includes ks=cdrom:/ks.cfg; I also removed the 'askmethod' command line which was preventing a fully unattended install. My abbreviated kickstart file is attached.
Actual results:
X starts, but Anaconda does not launch in graphical mode. Instead, the install is text-based (but you wouldn't know that unless you happened to switch away from the blank X screen back to VT1 where the install is happening.)

Expected results:
X should start and Anaconda should be running within it.

Additional info:
I did some debugging with this. I went to VT2 while the text anaconda was running and copied its argument list. I then killed anaconda and tried to reset the install environment as best I could (rm -rf /var/log and kill the existing Xorg process.) If I launched anaconda from VT2 with the precise commandline that was used during the install:

/usr/bin/python /usr/bin/anaconda --stage2 cdrom:///dev/sr1:/mnt/stage2 --dlabel --kickstart /tmp/ks.cfg --graphical --selinux

It works fine (well, it doesn't, because it complains about not being able to reformat my root partition, but that doesn't matter in the context of this bug.)

I copied /usr/bin/anaconda to /tmp, and made the following change right after the Xorg process gets forked with subprocess:

except (OSError, RuntimeError):
    stdoutLog.warning("X startup failed etc.")
--> raise

I did this so I could see the backtrace from Python. But of course launching this manually from VT2 also worked. On a whim, I did this (which would simulate anaconda being launched from a different process):

/usr/bin/python /usr/bin/anaconda --stage2 cdrom:///dev/sr1:/mnt/stage2 --dlabel --kickstart /tmp/ks.cfg --graphical --selinux </dev/null

And I got the error:

Traceback (most recent call last):
  File "/tmp/anaconda", line 923, in <module>
    signal.pause() <-- this line is located right after launching the X process
  File "/tmp/anaconda", line 905, in sigchld_handler
    raise OSError

I think this is the error that happened during the automated install, but I'm not 100% sure (since I did a lot of hacky stuff to get the error.) But I did see the same X blank screen.

Is it possible that X is starting a child process and killing it, which propagates SIGCHLD up the chain all the way back to Anaconda?

Another question is why does it only happen when I redirect stdin from /dev/null?

I'm doing more research, and will update the bug as soon as I get more details.

Comment 1 Chris Lumens 2010-04-26 20:40:22 UTC

*** This bug has been marked as a duplicate of bug 57965 ***

Comment 2 Chris Lumens 2010-04-26 20:41:05 UTC

*** This bug has been marked as a duplicate of bug 579654 ***

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