On Sun, 05 Sep 2010 20:08:14 -0400 (EDT), Tong <mlist4sunt...@yahoo.com> wrote: > On Sun, 05 Sep 2010 17:41:34 -0400, Stephen Powell wrote: >> I also use the nv driver, and I can start the X server multiple times, >> but usually not without manual intervention. What usually happens is >> that the old session only partially dies. The new session tries to grab >> vt 7, but finds it unavailable for allocation; so it allocates vt 8. If >> I switch to a text console with, say, Ctrl+Alt+F1, then if I attempt to >> switch back to X with Alt+F7, I see a black screen. But if I use Alt+F8 >> instead, I get back to X. Multiple restarts can force the use of higher >> numbered vts. > > YES! that's *exactly* the symptom that I'm experiencing. >> >> I have to jump through some hoops to get the X server back >> on vt 7. I usually just reboot because it's easier, but it is possible >> to do it without rebooting. > > I don't mind jumping through some hoops to get the X to start at VT 7. I > want to avoid rebooting as much as possible. How were you able to do that?
I run GNOME, so this technique may not work for you or may need to be adapted. But here's what I do: (1) I click on System -> Logout from the GNOME action bar. The logout completes, and the gdm daemon restarts, but not necessarily on vt7. (2) I switch to text console number 1 via Ctrl+Alt+F1, then attempt to switch back to X via Alt+F7. If I see a black screen, I know it restarted on the wrong vt. I don't know which one yet, but I know it's not vt7. (3) If I get a black screen in step 2, I switch back to text console number 1 via Alt+F1. (Note: the Ctrl key is not needed here, since X is not running on vt7!) (4) On text console number 1, I login as root. I find the console-kit-daemon process via ps aux|grep console-kit-daemon Sample output looks something like this: smp3:~# ps aux|grep console-kit-daemon root 1609 0.0 0.6 17424 3116 ? Sl Sep05 0:00 /usr/sbin/console-kit-daemon --no-daemon root 4274 0.0 0.1 3796 780 pts/0 S+ 09:51 0:00 grep console-kit-daemon smp3:~# I obtain the process id from the output of the above command, in this case 1609, and use it in the kill command: kill 1609 I can then deallocate vt 7 with deallocvt 7 I find that the "deallocvt 7" command fails unless I kill console-kit-daemon first. I also find which vt gdm started on via ps aux|grep gdm Typical output might look something like this: smp3:~# ps aux|grep gdm root 1080 0.0 0.4 16100 2072 ? Ss Sep05 0:00 /usr/sbin/gdm root 1087 0.0 0.6 16412 3252 ? S Sep05 0:10 /usr/sbin/gdm root 1094 0.7 6.6 41044 34180 tty7 Ss+ Sep05 10:40 /usr/bin/X :0 -audit 0 -auth /var/lib/gdm/:0.Xauth -nolisten tcp vt8 root 4294 0.0 0.1 3796 780 pts/0 S+ 10:03 0:00 grep gdm smp3:~# The above output shows it started on vt 8. I keep that in mind for later. Then I restart gdm with /etc/init.d/gdm restart The X server restarts on vt 7. When the restart occurs, the active vt automatically switches to vt 7 and I see the gdm login screen. I switch back to text console number 1 with Ctrl+Alt+F1, and repeat the process of finding and killing the console-kit-daemon process and deallocating vt 8 (or whatever vt it was on before). I then logout of my root session on vt 1. I then switch back to vt 7 via Alt+F7 and login. Note: it is important not to switch back to X between killing console-kit-daemon and deallocating the vt. For this procedure I owe someone else on this list who helped me months ago, but I don't remember who it was. But thanks again to you, sir, though I don't remember your name. This is clearly a bug. I shouldn't have to do this. The question is, against what Debian package do I report the bug? My first thought was against xserver-xorg-video-nv, but I have seen these symptoms (though less often) with other video drivers, such as intel. Perhaps console-kit is the right package, since it owns the executable whose process must be killed in order to deallocate the vt. If this process, or an adaptation thereof, works for you, you may be able to circumvent it by issuing (as root) mv /usr/sbin/console-kit-daemon /usr/sbin/console-kit-daemon.disabled killall console-kit-daemon But I don't know what other ramifications this might have; so I can't recommend it at this time. -- .''`. Stephen Powell : :' : `. `'` `- -- To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/818893726.634530.1283784124294.javamail.r...@md01.wow.synacor.com
