Tuesday, 15 June 2010

Nasty little log-in problem with Ubuntu 10.0.4

For some perhaps strange reason, I saw the following exception this morning when I tried to log into my freshly squeezed Ubuntu 10.04 32-bit installation on a 4061-BL5 Lenovo Thinkpad W500: -

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'm currently leaning on VMware, as I'd been able to log-in post a resume after the updates.

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:

Dave Hay said...

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 ...

Note to self - use kubectl to query images in a pod or deployment

In both cases, we use JSON ... For a deployment, we can do this: - kubectl get deployment foobar --namespace snafu --output jsonpath="{...