Red Hat Bugzilla – Bug 131899
can't switch to VT1: Ctrl-Alt-F1 generates junk
Last modified: 2009-03-11 05:38:57 EDT
From Bugzilla Helper:
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7.2)
Description of problem:
rhgb apparently doesn't enable you to switch to VT1 any more. Is this
on purpose? This would be very useful to see how fsck is going, for
Ctrl-Alt-F1 generates junk if you have details enabled, instead of
switching to VT1. FWIW, Ctrl-Alt-Backspace to kill it still works,
but that's a bit too disruptive.
Version-Release number of selected component (if applicable):
Steps to Reproduce:
1.Boot with rhgb
2.Try to Ctrl-Alt-F1 after it starts
Actual Results: Can't.
Expected Results: Would like to.
I didn't touch rhgb recently, I have no idea why this
What happens if the vte widget doesn't have keyboard focus?
It's X which for some reason desactivates the switch when run
under rhgb, the same X software with the same conf run at init 5
does the right thing. So I short-circuited the way the event is
handled and run "chvt 1", that seems to fix the problem in my
That should be fixed now in the rawhide version, anything past
0.13.1 should have the fix,
Ctrl-Alt-F1 now works, indeed, but F2..F7 still generate junk.
Mike, any idea of why X's behavior within rhgb might have changed so
as to disable VT switching?
Why do you want to switch to vt [2-7] ? Sorry I don't
think this adds anything during boot. That's why I did not
Please reopen only if there is a good reason to switch at that point.
It's not that I'd like to switch to a different VT, it's more like it
broke and we don't know why, and your workaround was hopefully just
that. We'd better figure out why X changed its behavior instead of
adding yet another layer of duct tape, bubble gum and goat blood :-)
Here's my own theory, however let me preface it by saying that I have
not tested or examined this problem directly. This is only a
_theory_, and subject to change as more details become available,
or the situation is directly investigated. </disclaimer>
I do not think anything has changed in X that causes this problem,
rather my belief is that we have changed the way X is used, and
that is causing the problem. Someone mentioned a few weeks back
that using X on a readonly filesystem caused xkb to break, as
it could no longer generate the XKB compiled keymaps when the
server starts. If rhgb is running on an entirely read-only
filesystem, and the X server can't generate xkb keymaps, then
there will likely be various odd keyboard related problems caused
Again, this is not a final conclusion, nor even a conclusion at
all really, just purely a personal theory as to what might be
causing this problem. If this does turn out to be the problem,
then we can explore the issue together, and discuss it on this
weeks X Devel team meeting.
mharris, would such xkb errors be logged to the X log file? DV, does
rhgb preserve this log file anywhere after it umounts /etc/rhgb?
can anyboday tell me how to disable the VT switching ..
user just wana work on default vt ..
We've reviewed this problem, and it is indeed caused by the read-only
filesystem environment in which rhgb starts the X server.
The X server invokes xkbcomp, and then tries to read in the files
xkbcomp spits out, however xkbcomp fails because it can't write to
the hard disk. Since this occurs, the keyboard can't be set up
correctly, and the CTRL-ALT-Fkey functionality needed to switch
VT's is unavailable.
This is not really a bug per se., but rather it is a hard coded
limitation in the current X server infrastructure, which requires
a read-write filesystem currently in order for xkbcomp to work
This should be filed in the upstream X.Org bugzilla at:
http://bugs.freedesktop.org in the "xorg" component, as it is
more of a feature request to resolve this. If someone does
file this upstream, it's possible it might get implemented
sooner. If so, please paste the upstream bug URL here for us
to track it.
I'm going to mark this bug as an FC4Target feature also, which
we'll review during FC4 development and assess wether this is
a big enough feature to spend time on within the FC4 timeframe.
This issue, as mentioned above, occurs because rhgb is invoking the
X server on a read-only filesystem and xkb requires a read-write
filesystem. Thus, as indicated above, this is a design limitation
of the X server rather than a bug.
Currently, we are planning on removing rhgb and replacing it with
starting gdm earlier on, which will also have this problem. As such
it is something we want to see the X server enhanced to support
in the future.
Enhancing the X server to handle startup in a read only filesystem
environment is being slated for review and consideration during the
FC5 development cycle.
Changing blocker to FC5Target.
As mentioned above a few times, this is not a bug, but a limitation in the
X server's current infrastructure. Overcoming this limitation needs to be
an upstream X.Org project. Please file a bug report or enhancement request
in X.Org bugzilla for this. It may end up being Red Hatter's that do the
work, but either way, it is an upstream issue that should get tracked
upstream. Merely filing it there, may even motivate someone to go ahead
and do the work.