PDA

View Full Version : Stubborn /tmp/.X0-lock file



PabloTwo
11th April 2007, 10:10 PM
I just moved from FC5 to FC6. After ironing one problem with the vidio driver that wasn't working quite right, I suddenly can no longer boot directly into the GUI. Though I get the graphical bootup screen, when it's time to plop into Gnome at the desktop, I'm instead left at the CLI. Fixing the first problem did not start the current problem, as I had a little bit of time between the two when all was working just fine.

The inittab file says I'm supposed to boot into mode 5 (GUI), but that's not happening. When I do 'startx', it tries but then I'm back at the CLI with a lot of error msg stuff. One item telling me I should delete the file '/tmp/.X0-lock' and try again. I delete that file then do startx again and everything is OK... until the next time I boot up and that darned file is back. Same situation. Any clues why that 'lock' file keeps coming back?

I haven't installed any apps that would run under the GUI. The only things I've installed since the FC6 install itself, about 4 days ago, is the nvidia graphics card driver, fuse and ntfs-3g to access an ntfs partition on my dual boot machine and a software modem driver.

Paul
Seville FL

mjmwired
12th April 2007, 12:48 AM
Look in: /var/log/Xorg.0.log
What do you see?
See if there are any (WW) warning or (EE) error.

PabloTwo
12th April 2007, 04:48 PM
mjmwired-

Thank you for a response. Here is what I'm able to determine thus far.

First, to correct an error in my original post, when I said "when it's time to plop into Gnome at the desktop", I should have said, "plot into the GUI logon screen".

There are no (WW) or (EE) entries in /var/log/Xorg.0.log, only (II) (--) (==) and (**) entries.

At the end of the the 'inittab' file, there is this entry:

# Run xdm in runlevel 5
x:5:once:/etc/X11/prefdm -nodaemon

With the above entry in inittab active, after the bootup process in GUI mode, it jumps right to the CLI logon screen without hesitation, with no error messages proceeding the logon prompt, and the /tmp/.X0-lock file is created. I have to delete the .X0-lock file before using 'startx'.

the .X0-lock file contains one line: <6 spaces>2499

With the above entry in inittab commented out, after the bootup process in GUI mode, it hangs with a blank blue screen with mouse cursor (mouse is active) for about 30 seconds or so, then drops me into the CLI logon screen. In that hang time I can just hear the boot process saying to itself, "should I let him have the GUI logon screen, or just give him the CLI?"

Also, with that line commented out, there is then no .X0-lock file created and I can just do 'startx' after logging in without any hassle.

I hope I've given enough clues/info here to help you help me.

Thank you

Paul
Seville FL

winstonfg
12th April 2007, 05:52 PM
Paul,

I'm by no means an expert with Fedora, but I'm familiar with other Unix's, and it seems to me that after your video driver change there may still be a problem wth the boot process. You might want to check the boot log for error messages. It's possible that during the process there's some sort of desktop initialization that leaves the lock file because it fails catastophically. 'Fraid I'm still a newbie to Fedora though, so it's just a suggestion.

Winston

Figment
12th April 2007, 05:58 PM
When it boots up to the CLI, try pressing CTRL-ALT-F7 to switch to virtual terminal 7, where X runs. A yum update should fix this problem.

I may be wrong about the issue, but try it out and see if it helps.

JustFly
12th April 2007, 06:18 PM
Hello,

Yes i also have had this problem..a big nuisance & one of the mysteries of linux for me until recent..-->alt-F7!! it helps me every boot :)

PabloTwo
12th April 2007, 06:35 PM
Thanks Fellows-

But I'm not looking for a 'work_a_round' to the problem, I'm looking to 'FIX' the problem.

On another note. I won't be doing any 'yum'ing until I get the modem driver working. It worked fine in FC5 but fails to load the hsfmodem driver at bootup in FC6. I do have the latest version FC6 kernel update rpm in hand though. When I get this other stuff fixed, I'll install that.

Paul

Figment
12th April 2007, 06:45 PM
Unfortunately, I don't know which package needs to be updated to solve the problem. However, many fresh installs of FC6 (including mine) have this. The reason the lock file appears is because your GUI is already running, just on a different virtual terminal. For some reason Fedora doesn't switch to it automatically. The key combination will switch to VT7, and the GUI should show up. It's annoying, sure, but it's definitely possible to use the system despite the problem.

And, like I said, the problem is fixed in the update of some package, because it disappeared after I ran an update. So, all I can think to say is update as soon as possible. Maybe somebody knows which package is the problem?

PabloTwo
12th April 2007, 07:10 PM
Figment-

OK.. next time I boot up Fedora I'll do the CTRL-ALT-F7 when I'm presented with the CLI logon screen before I logon and see if that switches me to the GUI logon screen, and if it does, then logon and see if that drops me into the GUI desktop, and if it does, I could probably live with that for awhile until I get some update stuff going.

The thing is, is that it worked as it should before, right after the initial install. But it's looking like I'm trying to make a horse with a broken leg not have a broken leg. My install is the first release of FC6, 2.6.18-1.2798.fc6.i686, probably rife with buggaboos.

Paul

SaGS
13th April 2007, 10:31 AM
I think the problem is https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=213824, see also http://lwn.net/Articles/207827/.

PabloTwo
13th April 2007, 04:09 PM
SaGS-

Thanks so much. I followed both links you provided. The second link, http://lwn.net/Articles/207827/
gave me the clue that I needed. It refers to an updated rhgb-0.16.4-3.fc6 module which addresses this problem. I downloaded that updated module from:

http://redhat.download.fedoraproject.org/pub/fedora/linux/core/updates/6/i386/

and installed it via 'rpm' from the local disk. Though it doesn't perform a perfectly clean fix, it does the job. Now there is no more having to hit CTRL-ALT-BACKSPACE at the CLI logon screen.

What it does, and I've done several reboots now to test it's consistency, is, after the boot process, hit you with the CLI logon screen, which only stays up for less than a second, then, in my case, gives me the Nvidia splash screen, then drops me into the GUI logon screen. Logon.......Done.

Very much appreciated

Paul
Seville FL