Ok, whew! I finally solved this doozy!

Somehow my /etc/X11/xkb/compiled symbolic link became an empty file rather than a symbolic link to my /var/lib/xkb directory.

I don't know how this symbolic link became an empty file. It doesn't appear, at a quick glance, to be related to any of Pat's recent upgrades.

This has got me a little puzzled, but I'm just tickled to have my consoles back when I log in at runlevel 4 via KDM

Hope someone else out there finds this useful.

Cheers all!

LocoMojo

Interestingly,

I have the exact opposite problem. All was working fine in FC4. Upgraded to FC5 -- which went very smoothly -- and I can only access VTs IF I USE KDM or GDM etc. If I start in run level 3, log in and run startx, I cannot use VTs. My symptoms are exactly the same as yours when you are using *DM. One more catch is if I run startx as root, I can switch to a VT with no problem. My current solution is to start my machine into KDM. But I prefer run level 3 -- because sometimes I don't run X.

Any thoughts?

You such luck here...I've been having this problem but I've been slacking for a long time. I have the /etc/inittab properly setup and I also have a /etc/X11/xkb/compiled symlinking the /var/lib/xkb directory. However, there is just a README file in /var/lib/xkb. Is that right?

I still can't switch between virtual consoles from run-level 4.

Tux,

It appears to be correct, at least my machine is set up the same way, and I can use virtual terminals from either startx or kdm (haven't tried gdm or xdm).
Regards,
Bill

Wow. The number of people overlooking what's been staring them in the face is kinda scary.

Anyway... the difference is the runlevel.

In runlevel 4, only vt6 gets a getty assigned to it. Trying to switch to virtual terminals 1-5 will get you nothing but a blank screen.

This section of /etc/inittab has been pasted before in this thread, but here it is again, and I'll explain what it does so things will be made clear:

Look at the second colon-separated field that has the numbers in it. What this field does is dictate during which runlevels that particular console will be active. The "1", "2", and "3" in each field mean that when the machine is in runlevels 1, 2, and 3, that these consoles will be activated. Notice the "4" in the line for c6 (console 6, aka vt6) and that it doesn't appear in any of the others. What this does is makes it so that when you're in runlevel 4, only c6 (vt6) is active.

I'll chime in and say that this is the default setup for runlevels in Slackware.

EDIT: at least in the latest releases.

Not as scary as the fact that you can't possibly have read the
the whole thread before lashing out :}

He clearly stated that the problem also occurred when he
booted into runlevel 3 and MANUALLY started KDM or
GDM ...


Cheers,
Tink

Really? Seems to me that you're the one who needs to read the whole thread before "lashing out". I read the entire thread very carefully actually (including the replies by threadjackers not even running Slackware).

Remember the bit where he was asked about his inittab before and said it was "intact"? He also quoted this from his process list:

This says pretty clearly that he's in runlevel 3, logged into vt1 (else where did tty1 go?). He might have noticed something was up if he'd done this from runlevel 4. Unless he's made some radical changes to his inittab there's no way this would be the result on a Slackware box from doing this in runlevel 4. No examination was made of this same information from runlevel 4. This is an important detail that added to my suspicion, fully explained below.

All the other things here (excluding the business with the xkb directory) are so impossibly obscure as to be ludicrous compared to the possibility that he panicked and didn't go for ctrl-alt-f6 after hitting F1 through F5, or that his F6 key got a bit of something under it and got stuck, or that he had DontVTSwich enabled in /etc/X11/xorg.conf, but a copy of the xorg.conf without it enabled in his home directory that he'd forgotten about. If there's one way that you can manifest a problem like this, this is it. Using startx, ~/xorg.conf will be read if it's there--if and only if you're root. Using gdm/xdm/kdm, it'll only be using /etc/X11/xorg.conf. As to xkb, well YEAH if you screw up keymappings, keys will stop working but I have my doubts about whether or not it could do this and leave any keys still working. I'm not really convinced replacing this symlink is what "fixed" the issue. Anyone want to try to replicate the problem for bonus points?

GDM and KDM have a lot of components, but XDM has nearly none--to the point where you might as well just throw out the DM and consider it to be a problem with X, itself. Anything able to affect XDM is almost certainly going to affect the other two as a result (while the converse is nowhere near necessarily true).

You've forgotten rule number one. When someone's gone through a long and winding batch of testing that results in an impossible and contradictory set of criteria, they've usually got one of the details wrong because they thought it was trivial or didn't understand the importance of it. When asked about inittab, he commented that it was "intact". "Intact" isn't enough. The machine isn't even going to boot if it's not there. Attention needed to be called specifically to inittab and the means by which consoles are assigned on a per-runlevel basis (especially considering how many people don't even know that they're started based on the runlevel).

First I thought of not even dignifying this with a response,
but I changed my mind; I'll let the original poster speak.
Cheers,
Tink

Then please feel free to explain how the apparent cause of this was supposed to even be possible instead of popping off another pointless insult. I tried to replicate the problem this morning by blowing away the symlink and it refused to manifest the same symptom.