Note: This is a beta release of Red Hat Bugzilla 5.0. The data contained within is a snapshot of the live data so any changes you make will not be reflected in the production Bugzilla. Also email is disabled so feel free to test any aspect of the site that you want. File any problems you find or give feedback here.

Bug 131899

Summary: can't switch to VT1: Ctrl-Alt-F1 generates junk
Product: [Fedora] Fedora Reporter: Alexandre Oliva <oliva>
Component: xorg-x11Assignee: X/OpenGL Maintenance List <xgl-maint>
Severity: medium Docs Contact:
Priority: medium    
Version: 3CC: byte, veillard
Target Milestone: ---Keywords: Triaged
Target Release: ---   
Hardware: All   
OS: Linux   
Fixed In Version: Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2006-01-18 00:24:12 UTC Type: ---
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:
Bug Depends On:    
Bug Blocks: 150221    

Description Alexandre Oliva 2004-09-06 14:58:55 UTC
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):

How reproducible:

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.

Additional info:

Comment 1 Daniel Veillard 2004-09-06 15:42:51 UTC
I didn't touch rhgb recently, I have no idea why this
regression appeared,


Comment 2 Bill Nottingham 2004-09-07 04:02:46 UTC
What happens if the vte widget doesn't have keyboard focus?

Comment 3 Daniel Veillard 2004-09-15 11:38:12 UTC
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


Comment 4 Daniel Veillard 2004-09-18 20:48:33 UTC
That should be fixed now in the rawhide version, anything past
0.13.1 should have the fix,



Comment 5 Alexandre Oliva 2004-10-02 19:48:24 UTC
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?

Comment 6 Daniel Veillard 2004-10-02 20:18:20 UTC
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
implement it.
Please reopen only if there is a good reason to switch at that point.


Comment 7 Alexandre Oliva 2004-10-02 20:34:32 UTC
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 :-)

Comment 8 Mike A. Harris 2004-10-03 05:30:50 UTC
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
by this.

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.


Comment 9 Alexandre Oliva 2004-10-05 12:03:22 UTC
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?

Comment 10 flower 2004-11-23 22:53:26 UTC
can anyboday tell me how to disable the VT switching ..
user just wana work on default vt .. 

Comment 11 Mike A. Harris 2004-12-03 20:44:29 UTC
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: 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.

Comment 13 Mike A. Harris 2005-04-08 12:14:16 UTC
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.

Comment 14 Mike A. Harris 2006-01-18 00:24:12 UTC
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.