Indeed this is really dumb.  Should be fixed for future, and also
in future erratum.  I'll leave this open until it's resolved properly.

Thanks.

Summary of team discussion: xfs initscript should not write out files
at all unless it specifically detects it needs to.  If it finds a
metadata file that is older than fonts present in the directory,
this is a situation which requires the metadata to be regenerated
in order for the fonts to be useable.  There are other problems
that can occur in the font directories, for which the xfs
initscript was designed to automatically fix.

So, if we change the initscript to detect read-only filesystems,
which would be very very tricky to get 100% correct due to the
various ways a filesystem can end up being read only, we can
then stop it from regenerating metadata and attempting to write
to the filesystem, however the end result can still end up
being unuseable fonts if the metadata is incorrect, which is
what xfs.init is trying to determine in the first place.

There are multiple problems in this scenario.  The above issue
with readonly filesystems is the second issue, but the first
issue is that the initscript still regenerates some metadata
files even when it does not need to, because the detection logic
is a bit flawed.

If we fix the first problem, by improving the logic used to
detect when to run mkfontdir, mkfontscale, ttmkfdir, fc-cache,
etc., then when the metadata files are all correct and updated,
the initscript should properly detect this and "just work" on
readonly filesystems.  I believe this is the best approach
to take for this for now.

However, if the metadata files are truely outdated, the initscript
will still detect this, and try to update them and generate errors
on readonly filesystems.  In my opinion this is a _wanted_ error
in this case, as the system administrator responsible for installing
the fonts and keeping the metadata files correct, needs to be made
aware of the problem if they are not correct.  If we do not fail
with an error of some kind in this case, then fonts just magically
do not work, and random applications inclusing X will receive
obscure bug reports from users about particular fonts not working.

Conclusion:  I will take this issue, and will rewrite the xfs.init
script to be more robust in detecting metadata files, so that it
is less likely to false-trigger metadata updates, and thus should
not blow up on readonly filesystems, unless there are real problems
the administrator should be made aware of.  In the latter case,
if it is possible to detect these failures easily, I will try
to make the error messages reflect the exact nature of the
failure case.

Upgrading back to fc4blocker, since I believe this is fixed by the
patch in bug 133451.

> The xfs startup script attempts to change protection on the fonts.dir directory
> in the /usr file system.  The RedHat documentation suggests that you should

xfs startup no longer calls chmod on the fonts.dir or other metadata
files located in the font directories, which solves the problem with
regard to chmod.

Instead, it relies on mkfontdir/ttmkfdir/mkfontscale/fc-cache to
set the permissions on updated metadata files properly.  umask is
set to 133 in the initscript, so any utilities that use default
permissions, should inherit this umask, causing files to be written
out as mode 0644 normally.

The logic in the initscript has been further enhanced to try to better
detect outdated metadata files, and only run mkfontdir and similar
utilities if the font metadata files are older than the fonts in the
directories.  The logic is not quite 100% perfect yet, but it should
handle most sane installations.

If someone mounts a filesystem containing fonts as read-only, which
has outdated font metadata, then the initscript will still fail, but
in this case it is pointing out a legitimate error with the font
directory, an error that would cause fonts to not work correctly in
the OS, and that is a case we want the user or sysadmin to be made
directly aware of.  If the filesystem containing the actual fonts
is properly updated so that it's font metadata files are correct, then
systems mounting the read-only filesystem containing these fonts should
no longer have problems with the new xfs initscript.

Please test ftp://people.redhat.com/mharris/xfs.init as a new initscript
in a read-only filesystem setup, and let us know if there are any
further problems that need to be ironed out.  We'd like to commit
these existing fixes to rawhide soon if no regressions are found
compared to the previous initscript.  If additional problems remain,
we'd like to know ASAP, so we can re-evaluate current status.

Thanks in advance.


Setting status to NEEDINFO

Actually, since we believe this is fixed now, RAWHIDE state makes
more sense, once 6.8.2-19 gets into rawhide.

This is still a problem in RHEL WS 4.

This bug was filed against Fedora devel originally, and is resolved in
Fedora devel.

In order to request a feature enhancement for RHEL 4 for this problem,
please visit the Red Hat Global Support website at:

    http://www.redhat.com/apps/support

Alternatively, you can contact Red Hat Global Support Services at
1-888-REDHAT1, to make a RHEL feature enhancement request.

Once you have contacted Red Hat GSS, our product management will
assess the viability of making this enhancment for future RHEL
updates.

Please make all RHEL support requests through Global Support Services,
which is our official mechanism for obtaining support for RHEL.

Thanks.

Re-closing Fedora Core feature request as fixed in rawhide.

From User-Agent: XML-RPC

xorg-x11-6.8.2-1.FC3.45 has been pushed for FC3, which should resolve this issue.  If these problems are still present in this version, then please make note of it in this bug report.