Bug 467793

Clarification, upon further experimentation: alt-ctrl-f1 produces a black screen; alt-ctrl-f2-6 appear to work correclty, displaying the virtual terminals; and alt-ctrl-f7 does NOT go back to X (it shows a black screen and the mouse pointer, but it is dead and unmovable). In case it is significant, I am using KDE (4).

In F10 if you start to init 5, the Xserver is by default started at tty1, therefore you should be able to return to X at his vt. More important is what graphics card you have and wherether you tried to disable modeseting (add kernel parameter nomodeset) and plymouth (remove parameter rhgb).

I had begun to think that plymouth was using virtual terminal 1, so that explained the black screen, but neither virtual terminal 1 nor ctrl-alt F7 (the 'old' or usual standard) returned to my X session. As stated, virtual terminal 1 is just black and alt-ctrl-F7 is also black, but with a dead mouse pointer on it. It is not possible to break out of this without alt-SysRq-reisub.

So, to answer some question just posed, I am using the onboard Intel graphics. My kernel boot line has: rhgb vga=0x31b. I was under the impression that modesetting would not work with Intel until kernel-2.29.

Yes, later, I can try removing rhgb and inserting nomodeset.

Ok, I just rebooted, and edited my kernel boot line in grub.conf, taking out rhgb vga=0x31b and putting in nomodeset. Since I removed vga=0x31b, I was not able to see plymouth's pretty blue screen and the framebuffer did not start, so all was black until after nash started (where the udev stuff is initialized). Once logged in, I tried alt-ctrl-F1 and got the black screen (no X), alt-ctrl-F2-F6 produced the virtual terminals, and alt-ctrl-F7 returned me to my running X session.

So, do I have the wrong things on my kernel boot line in grub? I read that, until modesetting is available (I read that it will not be available for Intel until kernel-2.29), one should use the framebuffer by putting vga=0x31b after rhgb on the kernel boot line in order for the plymouth video to display. Is my understanding correct? should I leave that and add nomodeset, too? I am confused about the proper arguments.

So, I decided to reboot yet again. This time, I removed only rhgb, left vga=0x31b in place, and appended nomodeset.

The result was that the framebuffer started, but there was no pretty blue plymouth display, and when udev started, I began to see some output. Once logged in, I tried the keys again.

This time, alt-ctrl-F1 gave me the black screen, and if I recall correctly, there was a flashing underline in the upper left corner, alt-ctrl-F2-F6 gave me the virtual terminals, and they were shown tiny, like the framebuffer shows them, not like normal, as was my previous attempt (see previous post), and alt-ctrl-F7 returned me - successfully - to my running X session.

So, what can I conclude here? That I can either use or dispense with vga=0x31b, that I need nomodeset (until kernel-2.29 when modesetting for Intel is in the kernel), and that I must remove rhgb (that means, just a black screen, no more blue plymouth screen). Or else I leave it and don't use the virtual terminals?

Or can you fix something?

The framebuffer vga=0x31b nasty solution:
http://fedoramagazine.wordpress.com/2008/10/21/interview-fedora-10s-better-startup/ 
Adam Jackson: There’s also a secret cheat code to run the graphical plymouth splash on vesafb, which is of course wildly unsupported. (vga=0x318 on the grub command line)

If you are not using it, you should see text plymouth boot up (blue progress bar at the bottom of the screen). 

Did you updated from F9, or is this new F10beta installation?

There was also a bug in firstboot that would break vt switching for the one boot cycle where firstboot runs.  should be fixed in firstboot-1.101-1, although that might not be what you're seeing here.

I installed f10alpha to a clean partition and kept on doing the updates. Before I learned of the vga=0x3xx grub parameter, I had that bar across thebottim, in 2 shades of blue and white, showing progress. I don't know what each colour symbolizes, it at least you know it's making progress :)

Could you please upgrade to the latest Rawhide packages? There was some shifting of X between VT7 and VT1 (we are now back at VT7) and some nasty problems with keyboard in relation to the Xserver.

I have all of the latest rawhide updates for my system installed. I just gave it a try again. As I had said earlier, and so it still is: vt1 is just a black screen (I presume this is the one that plymouth or the framebuffer uses), vt2-vt6 are fine and show the login prompt (I did not attempt to log in), and vt7, which is supposed to return me to my active X session, gets me to a black screen with a dead mouse pointer. After having done this, it is impossible to do anything. I cannot return to one of the virtual terminals, I cannot move the mouse, I cannot kill the X server with alt-ctrl-backsp, nor can I gently bow out with alt-SysRq. The system is locked dead. I can only push the power button and restart.

(In reply to comment #9)
> Could you please upgrade to the latest Rawhide packages? There was some
> shifting of X between VT7 and VT1 (we are now back at VT7) and some nasty
> problems with keyboard in relation to the Xserver.

I have fully updated my rawhide installation, but I still has X server at vt1.

Some progress has been achieved. With kernel-2.6.27.4-51.fc10.i686, I just tried it again. The result:

vt1 is a black screen with nothing else on it
vt2-vt6 have a login prompt (I did not try to log in)
vt7 finally DID return to the running X session (no more pressing the power button to reboot)

A post on fedora-devel, I think, suggested that vt1 is supposed ot be X and vt7 is no longer, but that is not how it is on this computer with the aforementioned kernel.

Petrus I think I know how your problem happens, because I was able to reproduce it today when I was triing to move the X in f10 from default vt1 to vt7.
This is because both mingetty and X server are started at vt1. For me it shows in processes that I have mingetty running on tty1 and Xorg on vt1 too. This happens when you enable tty1 in upstart (this could remain in your installation from past), but plymouth is forcing X to start at vt1, thru gdm parameter (the process is somehow too complicated to discribe here). Please make sure, you do not start mingetty on tty and everything works (besides that now we all have X at vt1, but this is another story).

This bug appears to have been reported against 'rawhide' during the Fedora 10 development cycle.
Changing version to '10'.

More information and reason for this action is here:
http://fedoraproject.org/wiki/BugZappers/HouseKeeping

I think we can close this bug, because this is a problem of setup (mingetty and Xorg at vt1), if we do not want to fix the problem that it is possible to start X at the VT that is already busy though. Or maybe it is a problem of mingetty starting at VT that is already busy?

The problem appears to be resolved in f11 alpha. I just tested and it worked correctly.

Wonderful, thank you for letting us know.