Hide Forgot
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): xorg-x11-0.0.6.6-0.0.2004_03_11.6 How reproducible: Always Steps to Reproduce: 1. Boot FC2-test1 with rhgb enabled 2. 3. Actual Results: Should show graphical boot screen Expected Results: Does not show graphical boot screen Additional info:
pts/19 mharris@porkchop:~/rpmbuild/rpms/XFree86$ grep XTMPPATH *.patch pts/19 mharris@porkchop:~/rpmbuild/rpms/XFree86$ 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. Daniel
I think we can close this. We don't rely on XTMPPATH to get rhgb to work. Daniel