Gregory P. Ennis wrote:
On Wed, 2006-01-18 at 10:06 -0600, Gregory P. Ennis wrote:
On Wed, 2006-01-18 at 09:40 퍍㐶⠞镦鵻૨뗡ꭺਫ죱➞⬰꺋帍 List,
I have had two desktops that have had their gui stop working over the
weekend. Both were E-Machines with ATI Mach64 video cards using
Princeton Ultra 72 and Ultra 74 monitors. I have other E-Machines with
different cards using the same monitors that are still working.
These two machines functioned without problems until the following
updates occurred : ( I can boot each to runlevel 3 without difficulty)
Jan 14 14:24:38 Updated: system-config-bind.noarch 4.0.0-38_FC4
Jan 14 14:24:41 Updated: flex.i386 2.5.4a-35.fc4
The above only represents one machine, because I rebuilt the os on the
other before I recognized it was not my mistake. I currently do not
have bind running nor do I use flex on either machine.
Other observations that I have made include the X.org.0.log entry of:
Could not init font path element unix/:7100, removing from list!
Fatal server error:
could not open default font 'fixed'
I have also noticed that the xfs daemon is not running and when I try to
start it manually I get a "Segmentation Fault" error.
Has anyone else reported problems related to these updates. Can any of
you help me.
Thanks,
Greg Ennis
I'm not running FC here at work, so can't give specific answers, but I might
have some general pointers you could check.
When xfs starts it opens a unix domain socket, port 7100, to listen for requests
(hence the "font path element unix/:7100" above). On RHEL this is in
/tmp/.font-unix/fs7100. Does this file exist, is there a problem with the /tmp
or /tmp/.font-unix directory? This is how /tmp/.font-unix and
/tmp/.font-unix/fs7100 appear on my RHEL system:
drwxrwxrwt 2 root root 4096 Jan 4 08:54 /tmp/.font-unix/
srwxrwxrwx 1 root root 0 Jan 18 09:35 /tmp/.font-unix/fs7100
Can you run xfs manually, via strace, to see what system calls it makes, and if
one is failing somewhere and causing it to abort? It might help pinpoint the
location of the problem. A seg. fault is not normal when starting xfs ;-)
--
Nigel Wade, System Administrator, Space Plasma Physics Group,
University of Leicester, Leicester, LE1 7RH, UK
E-mail : nmw@xxxxxxxxxxxx
Phone : )116 2523548, Fax : )116 2523555
Nigel,
Thank you for your help. Here is some information as to your questions.
This information came from a unit that was a new install of an
"E-Machine" that worked well until I did an update with yum -y update.
The update was done immediately after the install After the update the
gui login screen has failed. I have two other units (all of which are
E-Machines) that have been running about 2 months without difficulty.
I posted a bug report with Red Hat, but they feel like this is a config
problem and directed me back to this list. It may be a config problem,
but it is not one that I or the other users have created in that this
the data below comes from a new install.
Unfortunately, this problem has left the units unusable for the users,
and will need to be fixed for us to continue the migration from MS to
FC.
Your help will be greatly appreciated!!!!
Greg
Dear List,
I am in a jam with 3 Fedora units that had their gui become unusable
after the 14th. One was even a fresh install that only became disabled
after the yum update was done.
This is really hurting the Fedora conversion effort with my client. If
any of you can help me I would greatly appreciate it. I am going to
have to return these units to MS if I can not get the problem fixed so I
would appreciate your help!!!!
Thank you,
Greg
Maybe have a look at your /etc/X11/gdm/gdm.conf file? Compare with
/etc/X11/gdm/factory-gdm.conf file?
--
-------------------------------------------------------------------------------
"The two most common things in the | Bill Perkins
universe are Hydrogen and Stupidity." | perk@xxxxxxx
| programmer-at-large
F. Zappa | ALL assembly languages done here.
-------------------------------------------------------------------------------
