From Bugzilla Helper:
User-Agent: Mozilla/5.0 (compatible; Konqueror/3.2; Linux) (KHTML, like Gecko)
Description of problem:
While trying to find out, why rhgb doesn't work anymore after upgrading to xorg, i looked into rhgb's sources and found out that it sets XTMPPATH envvar to make X create tmpfiles in /initrd. However, this var is not used by xorg and thus it fails to start during first start of rhgb because /tmp ist still mounted readonly at that time. The second attempt of starting rhgb in rc.sysinit is never executed, because at the first attempt, the shell variable RHGB_STARTED is set to 1 unconditionally.
Version-Release number of selected component (if applicable):
Steps to Reproduce:
1. Boot FC2-test1 with rhgb enabled
Actual Results: Should show graphical boot screen
Expected Results: Does not show graphical boot screen
pts/19 mharris@porkchop:~/rpmbuild/rpms/XFree86$ grep XTMPPATH *.patch
While jrb did write a patch to add support to XFree86 for recognizing
the XTMPPATH environment variable, it was never accepted into upstream
XFree86 CVS, and has never been applied to any official Red Hat
XFree86 builds. xorg-x11 is based on XFree86 4.4.0RC2, which also
does not support XTMPPATH.
Since we've never had XTMPPATH support in our X packages, I do not
see this as an XFree86 or xorg-x11 bug, and I'm not sure why rhgb
would rely on an unsupported feature we've never shipped.
Reassigning to rhgb component for further comment ...
Rhgb still defines XTMPPATH, there was a good reason which was
to load the right keymap (which needs a temporaryfile).
I don't know if XTMPPATH is used or not, but X definitely starts
on /etc/rhgb (I moved rhgb out of /initrd) with x.org here and
on all recent Fedora setups.
We are working around the lack of XTMPPATH support as much as possible.
I think we can close this. We don't rely on XTMPPATH to get rhgb to