From Bugzilla Helper: User-Agent: Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.1; .NET CLR 1.0.3705) Description of problem: After install the last set of RPM's to XFree86, receiving the following message for xserver startup: Fatal server error: could not open default font 'fixed' Version-Release number of selected component (if applicable): XFree86-4.3.0-63 How reproducible: Always Steps to Reproduce: 1.Install XFree86 RPM's 2.Restart system 3. Additional info:
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.