There is a problem with the configuration server. (/usr/lib/libgconf2-4/gconf-sanity-check-2 exited with status 256 )
which then bounced me back to the default Gnome log-in screen.
along with exceptions such as: -
Jun 15 08:58:25 dmhw500 gdm-simple-greeter[9222]: WARNING: could not get gconf key '/apps/gdm/simple-greeter/recent-languages': Failed to contact configuration server; some possible causes are that you need to enable TCP/IP networking for ORBit, or you have stale NFS locks due to a system crash. See http://projects.gnome.org/gconf/ for information. (Details — 1: Could not send message to GConf daemon: Process /usr/lib/libgconf2-4/gconfd-2 received signal 6)
and: -
Jun 15 08:58:25 dmhw500 gdm-simple-greeter[9222]: WARNING: could not get gconf key '/apps/gdm/simple-greeter/recent-layouts': Failed to contact configuration server; some possible causes are that you need to enable TCP/IP networking for ORBit, or you have stale NFS locks due to a system crash. See http://projects.gnome.org/gconf/ for information. (Details — 1: Could not send message to GConf daemon: Process /usr/lib/libgconf2-4/gconfd-2 received signal 6)
in /var/log/syslog.
Now I had performed a clean installation of the 32-bit version of 10.04 yesterday, because the 64-bit version was causing a bit too much pain with applications such as my VPN client etc.
The installer automatically laid down the Physical Address Extension (PAE) kernel: -
Linux dmhw500 2.6.32-22-generic-pae #36-Ubuntu SMP Thu Jun 3 23:14:23 UTC 2010 i686 GNU/Linux
Now there's two possible causes for this: -
- installing VMware Workstation ( VMware-Workstation-Full-7.1.0-261024.x86_64.bundle )
- A post-10.04 update
I'd also noticed that I wasn't able to start VMware as my normal user ( hayd ) but was able to start it as root ( via sudo /bin/bash ). I didn't dig into this too much, but I'm fairly sure that VMware was complaining about access to something in /tmp.
Anyway, back to my lack of login ....
I'd Google'd around, and found a few references to this problem, most of which appeared to indicate that permissions to the /tmp folder might be the problem - which ties up nicely with VMware not playing ball.
Ordinarily, I'd simply switch to another virtual terminal via Ctrl + Alt + F1 etc. but this doesn't appear to work for me on Ubuntu, perhaps due to the display driver that I am currently using - i915 - as Ubuntu has offered me the option to install the proprietary AMD/ATI driver fglrx - an offer which I've not yet chosen to accept.
To cut a long story short, I needed to boot the Thinkpad from the 10.04 installation, choose to run Ubuntu in "live" mode ( rather than reinstalling ), and then open a normal xterm console.
I also needed to mount my hard drive, via Places -> Computer, so that I could access it via the shell session.
From the xterm command, I ran the following commands: -
sudo /bin/bash
cd /media/
chmod a+rwx /tmp
The last command sets the permissions for ALL users, via the a flag to be Read/Write/Execute.
Having done this, I rebooted ( having removed the DVD ), and was able to log in as usual.
Again, I'm not 100% sure why this happened, *BUT* it was a somewhat scary moment, having spent nearly two hours installing and patching 10.04 having gone back to 32-bit.
Still, another lesson learnt ....
1 comment:
Well, it's just happened again - still unable to access any virtual terminals using CTRL + ALT + Fx, and same error on login.
Just to add some more detail on the recovery, having booted into the LiveCD mode via the 10.04 DVD, I chose Places -> 154 GB Filesystem ( which is the name of my hard disk ).
This causes the file system to be mounted and, under xterm it appears as: -
/media/61544394-5175-405a-b8e7-e82323681f2d/
If I run the command: -
ls -al /media/61544394-5175-405a-b8e7-e82323681f2d/
I can see /tmp: -
drwxr-xr-x 6 root root 4096 2010-06-15 12:48 tmp
whereas I believe it should be something similar to: -
drwxrwxrwx 11 root root 240 2010-06-15 12:55 tmp
Once I change the permissions using the command: -
sudo chmod a+rwx /media/61544394-5175-405a-b8e7-e82323681f2d/tmp
I see: -
drwxrwxrwx 6 root root 4096 2010-06-15 12:48 tmp
which looks better to me.
I now need to find out what's breaking it - I did run up VMware Workstation having fixed the problem earlier, so that's where my testing will begin ...
Post a Comment