Bug 118145

That error message indicates misconfigured/misinstalled X11 core
fonts, and is not an XFree86 bug.  If you have installed your own
fonts aside from those that come with the distribution, you may
wish to search for the Font HOWTO on google, which contains useful
information on resolving this type of misconfiguration problem.

Alternatively, you may wish to try the xfree86 mailing
list to seek technical assistance in reconfiguring things properly.

If you search www.google.com for the error message above, you will
also find that this particular error, indicates common
misconfiguration, along with examples of how to investigate fixing
your local configuration.

While it is kind of unlikely our XFree86 or fonts have a bug that
is causing this problem for you, I will leave this open for a while
to see if any other users report similar issue, just to be safe.
If there does turn out to be a bug in our XFree86 packaging with
regard to fonts, or in any of our font packages, numerous users
will experience it and we'll receive many bug reports.

In the mean time, if you'd like to test for sure wether this is
a configuration issue, you can do a fresh OS installation from
scratch of Fedora Core test1 and try to start the X server.  Or,
you can do a fresh install of a previous OS release and upgrade.
In both cases, font configuration should work properly.

Hope this helps.
I'll update this report in a week or so.

Hmm, I have similar experience, I temporarily solved it by commenting

#       FontPath     "unix/:7100"

option in /etc/X11/XF86Config. This problem appeared really after
yesterday's upgrade to XFree86-4.3.0-64 and I have installed no other
fonts, than those available in distribution.

It seems to be OK after installing xorg-x11-0.0.6.6-0.0.2004_03_11.6
packages, the problem seem to be gone and xfs is fully working for me now.

This problem is a temporary issue caused when upgrading from
XFree86 to xorg-x11.  The reason it happens is due to the order
in which rpm processes the various package's rpm scripts.  The
new packages add xfs via chkconfig first, and then rpm processes
the old (XFree86-xfs) scripts which remove xfs.  As a result,
once you've upgraded to xorg-x11, even though xorg-x11 packaging
is doing the right thing and properly adding xfs, rpm's ordering
of the scripts causes xfs to be unconfigured.

This is therefore actually a bug in the way the XFree86-xfs
rpm scripting is written which has gone unnoticed because it is
a codepath that would almost never get used.

This problem is difficult to solve in a clean and easy way, and
might not even be 100% solveable due to the order scripts run in.

My current plans on attempting to resolve this are to first fix
the XFree86 packaging to remove the bad script code, so that
future XFree86 erratum for Fedora Core 1, Red Hat Linux 9, and
Red Hat Enterprise Linux 3, will not have this xfs rpm script
issue, thus reducing the chance of users experiencing it when
upgrading their OS in the future.   Additionally, I will be
examining in greater detail the order rpm processes the various
types of scripts when installing/upgrading, and see if there
is a clean way which the scripts can be enhanced to do the
right thing from the xorg-x11 packaging.  If that's not possible,
I will investigate the use of rpm triggers to correct the problem,
but that may create more problems than it would solve.  It's worth
investigating nonetheless.

In the mean time, users experiencing this problem can work around
this issue either by:

- Upgrading from their currently installed xorg-x11 release to a
  newer xorg-x11 release when one becomes available.  The xorg-x11
  to xorg-x11 upgrade script handling and XFree86 to XFree86
  upgrade handling should do the right thing.  The only problem
  case is XFree86 -> xorg-x11 upgrade handling.

or

- By logging in as root, and running:
    /sbin/chkconfig --add xfs
    /sbin/service xfs start

I'll update this report again once new information becomes available,
or if updated packages become available to test.

Thanks.

*** Bug 118818 has been marked as a duplicate of this bug. ***

FWIW the xfs user is also getting deleted and needs to be recreated if
you want things to be as secure as before. (Unless you use the trigger
scripts I attached to bug 118448, which will do that for you when you
upgrade from XFree86-xfs to xorg-x11-xfs.)

<notting> removing the userdel/groupdel from xfs %preun is a good idea
for future maintenance too

Here is the original %preun xfs still present:

%preun xfs
{
  if [ "$1" = "0" ]; then
    /sbin/service xfs stop &> /dev/null || :
    /sbin/chkconfig --del xfs || :
    /usr/sbin/userdel xfs 2>/dev/null || :
    /usr/sbin/groupdel xfs 2>/dev/null || :
  fi
}

The above should only get executed when the package is finally
removed, such as "rpm -e <package>.  The upgrade from XFree86
to xorg isn't considered an 'upgrade' by rpm since the package
names are different, and as such, it considers it an uninstall
and executes the script code above.

Disabling the userdel/groupdel is no problem as the user/group
is reserved and can just stay present indefinitely without harm,
however there is still a problem with chkconfig.  The chkconfig
really does need to be there, so that if you just do:

rpm -e XFree86-xfs

or

rpm -e xorg-x11-xfs

... chkconfig gets ran and deconfigures xfs from being available
to choose in ntsysv et al.  I'm not sure how to handle that other
than by putting a permanent trigger in every future package that
contains xfs, to automatically trigger on every previous package
that contained xfs.  That's rather ugly.

In other words, with the existing triggers Barry supplied (slightly
modified), the problem still exists that if xorg-x11-xfs gets
uninstalled, chkconfig --del is called.  If for example that was
to upgrade to YAXI (Yet Another X11 Implementation), then we have
a resurfacing of the chkconfig issue, only this time it would be
from upgrading from xorg-x11-xfs to foobedoo-x11-xfs.  IOW, I'm
trying to prevent future problems ahead of the ballgame.

Any ideas?

Nope, it's standard operating procedure that if an initscript moves to
a different package name, you need a trigger.

Ok, thanks for the feedback Bill.  I've never had a package with
an initscript move around like this before, so it's new to me.  ;o)

I've added the triggers to the .8 build, going into beehive as
I type...

Fixed in rawhide, in xorg-x11-0.0.6.6-0.0.2004_03_11.8, which will
be available tomorrow sometime.