Description of problem:
The console window manager fails to start up with
repeated messages recording in /var/log/messages:
gdm[nnnn]: gdm_slave_xioerror_handler: Fatal X error - Restarting 0
Following a suggestion obtained through the web, we commented out
the following line in /etc/X11/XF86Config:
the display manager can then come up normally.
However, we can now log on using the root account only.
When we tried to log in using a normal user account,
a small window pops up saying there are problems detected.
It then reverts back to the normal logon screen.
The system is part of a NIS client, but we can log on
remotely using ssh (ie. non window) with the normal user accounts.
In the system log /var/log/messages, it reports:
gdm(pam_unix)[nnnn]: bad username [pcmc]
gdm-binary[nnnn]: Couldn't authenticate user
gdm(pam_unix}[nnnn]: session closed for user pcmc
The system has been working fine (without a reboot) until today.
Version-Release number of selected component (if applicable):
How reproducible: everything
Steps to Reproduce:
1. log in using a normal user account
A window pops up saying problems detected.
The screen reverts back to normal logon screen.
Normal log on.
In the up2date log (/var/log/up2date.2), on Nov 18,
there had been a number updates on XFree86-4.3.0-2.90.43
and relating products.
Not sure if that is relevant to the problems now experience.
It appears that we have got round the problem afterall.
The gdm_authentication error was later traced down to the
/tmp directory protection. Somehow, it was set to 755.
By resetting it to 1777, normal users can now log on the console.
We still don't know how that fault was caused in the first place.
We are not sure also that the FontPath in XF86Config and xfs are
still needed afterall. We still have the FontPath commented out.
It would be nice if GDM gave a more descriptive explanation of the
problem in this case, so that misconfigurations could be more quickly
identified. I'm going to change this bug to an enhancement request
and alter the bug summary as appropriate.
I logged this bug upstream. You can track its progress there: