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
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.
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.)
X should start and Anaconda should be running within it.
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.")
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
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.
*** This bug has been marked as a duplicate of bug 57965 ***
*** This bug has been marked as a duplicate of bug 579654 ***