No virtual terminals with XForum: X and Fluxbox Topic: No virtual terminals with X started by: tbielawa Posted by tbielawa on June 13 2005,04:27
With X running, I can’t seem to access any of the other virtual terminals. Pressing Ctrl-Alt-F1 takes me to a black screen, and I have to power off the computer to get out of it. Similarly if I boot into run level 2 and then go to run level 5 when X starts the screen goes black and the system stops responding. When stuck in the black screens, the computer does not seem to respond to any key press. Ctrl-Alt-Del, Ctrl-Alt-BKSpace, and Ctrl-Alt-Fx all have no effect. I have seen the same problem on both a Dell Dimension 4600 and in Microsoft Virtual PC.
Posted by SaidinUnleashed on June 13 2005,05:07
The solution is simple.Use the Xterm. Posted by reidar on June 13 2005,07:00
I don't think there are any virtual terminals in DSL (that you can access by pressing Ctrl+Alt+n) like in Debian and other distros. I guess the closest you get is by pressing Ctrl+Alt+Backspace while in X. But normally you just use xterm, like SaidinUnleashed said.-r Posted by tbielawa on June 13 2005,14:08
That's not a solution as I intent to boot into run level 2 and switch to run level 5 and X only when needed. This work around also causes problems if I should accidentally hit Ctrl-Alt-Fx while in X. The system will become hosed.
The virtual terminals are present. If you look in inittab you can see that 4 virtual terminals are being setup. Booting into run level 2 verifies that they are there and functioning properly. You can access all 4 by pressing Ctrl-Alt-F1 through Ctrl-Alt-F4. Note that when in runlevel 5, only one of the virtual terminals is present.
Doesn’t work. I just get the black screen, and have to power off the system. Posted by tbielawa on June 13 2005,14:27
An update on the symptoms:While trapped at the black screen, the system is not completely broken as I previously though. If I start the SSH server before trying to switch virtual terminals, I can still log in to the machine through SSH while stuck at the black screen. So this seems to but just a display problem. When logged in through SSH, I can kill off and restart all of the X and tty processes to no effect. Posted by mikshaw on June 13 2005,15:22
Look into /etc/inittabThis file sets up the virtual terminals...you can see that only one is created in runlevel 5, and four are created in runlevel 2. Maybe you can make some changes to this. Posted by tbielawa on June 13 2005,16:17
As stated previously, there are four fully functional virtual terminals in run level 2, no problems here. In run level 5 with X running there are no virtual terminals (when there should be 1 according to inittab). Modifying inittab to create 4 virtual terminals in run level 5 does not change there behavior seen. There are still no virtual terminals while X is running. A bigger issue here than the lack of virtual terminals while X is running is that if you press Ctrl-Alt-Fx your system is hosed and you need to reboot. Posted by tbielawa on June 17 2005,01:14
Update:Booting with the vga=normal cheat code solves the problem on all of the machines I've tested on. I have yet to find the reason behind the problem, or why this fixes it. All other vga=7xx codes experience the issue. Posted by mikshaw on June 17 2005,16:33
As stated previously, inittab handles your virtual terminals. The one that you see listed in inittab for runlevel 5 does exist, but it is used for the X session. Runlevel 5 in debian systems is equivalent to runlevel 3 in many other distros, except that 'startx' is run as soon as you log in. Exit fluxbox and you be in a terminal.Here's what i did to get multiple terminals in runlevel 5, without needing to change my display settings: This is in the original /etc/inittab 1:12345:respawn:/bin/bash -login >/dev/tty1 2>&1 </dev/tty1 2:234:respawn:/bin/bash -login >/dev/tty2 2>&1 </dev/tty2 3:234:respawn:/bin/bash -login >/dev/tty3 2>&1 </dev/tty3 4:234:respawn:/bin/bash -login >/dev/tty4 2>&1 </dev/tty4 I changed it to this: 1:12345:respawn:/bin/bash -login >/dev/tty1 2>&1 </dev/tty1 2:2345:respawn:/bin/bash -login >/dev/tty2 2>&1 </dev/tty2 3:2345:respawn:/bin/bash -login >/dev/tty3 2>&1 </dev/tty3 4:2345:respawn:/bin/bash -login >/dev/tty4 2>&1 </dev/tty4 Now i have 3 additional terminals in runlevel 5. I get to the others with Ctrl+Alt+F#, and get back into X with Alt+F5 Posted by tbielawa on June 17 2005,16:37
That was the first thing I tried, and it doesn't work for me on 5 different computers and in Virtual PC. The only way I can get to the virtual terminals is by booting with vga=normal. Maybe I just got "lucky" with the machines I'm testing on.
Posted by mikshaw on June 17 2005,16:59
I can't figure out what the problem would be then. All I can think that might be causing the black screen is if you were in tty3 or tty4 when you went back into runlevel 5, since those terminals don't exist in runlevel 5 by default....but that's just a guess and i haven't tested it. It seems that Alt+F2 should have taken you back into X. Another guess is that maybe you had X started in runlevel 2 on a higher terminal than is available in runlevel 5, but again i'm just shooting out theories. For all i know these things could have no affect at all.This is something worth playing around with, though...i'll post again if i find anything interesting. Posted by tbielawa on June 17 2005,18:16
My current experimental setup has 4 virtual terminals in all runlevels to avoid such problems, and I always start X by switching to runlevel 5 and letting the scripts take care of the rest. Be carefull with multiple virtual terminals in runlevel 5 as startx is called by .bash_profile for user dsl. If you log out of a virtual terminal, startx will get called again. I don't know if this will help any, but on all of the physical machines I'm testing on, I get a "Invalid Mode Number Passed" error at boot if I don't use the vga=normal cheat code. This error does not occur in Virtual PC however, but the virtual terminal behavior is still the same.
Posted by mikshaw on June 17 2005,19:44
That's something that i took care of long ago. I don't like automatically going into X, so removed startx from .bash_profile.That said, I found a solution that works for me...don't know if it would work for you. What I had posted earlier only worked because i switched to runlevel 2 and then back to runlevel 5. If the edited inittab was part of a backup, it does not automatically work because init has already run long before backups are restored. So what i did was add "telinit q" to /opt/bootlocal so that /etc/inittab will be re-read after the file is restored from backup. As long as startx is removed from the picture, the result is four terminals logged in as user dsl. Manually entering 'startx', as i typically do anyway, gives me an X session plus three extra terminals. The only difference now between this and the standard setup is that the terminals are already logged in. I'll have to look into that a bit more to see if there is a way around it in DSL. Posted by tbielawa on June 17 2005,19:57
Doesn't work for me. I guess I'm just going to have to stick with small virtual terminals.
Go into inittab and replace: 1:12345:respawn:/bin/bash -login >/dev/tty1 2>&1 </dev/tty1 with: 1:12345:respawn:/sbin/getty 38400 tty1 Posted by mikshaw on June 18 2005,03:34
looky there...you come here hoping for an answer and give more help than you get. The one minor issue with your suggestion is that it requires the 'secure' boot option because the getty requires a password. Apart from that tiny detail...Thank you! It's exactly what I was hoping for.Sorry i don't know what else to say....it works here and i don't know why it doesn't work for you =o( Posted by tbielawa on June 18 2005,04:16
Another option is to make a remaster with the passwords already set. I did this so I could have ssh access to a headless machine. In DSL 1.1 this was as simple as booting off the CD, running passwd, as remastering without changing anything. In DSL 1.2 this doesn't work because the password files are on a read only file system of course. I'm still trying to figure out what changed from DSL 1.1 to DSL 1.2 to break this, but after seeing the error I'm not sure it should have ever worked in DSL 1.1.
Posted by mikshaw on June 18 2005,04:22
Do you think it would work to boot with 'secure', set the passwords, and then back up /etc/passwd? As far as I can tell it's a file that can be overwritten from backup even in 1.2
Posted by tbielawa on June 18 2005,04:34
I've never used the 'secure' cheat code, or the backups and restores. I've always just done a quick remaster instead. I don't see why it wouldn't work, assuming the password files are restored soon enough. /etc/passwd doesn't actually contain the password hashes anymore. The hashes are in /etc/shadow. I think there might still be important information in /etc/passwd that gets updated when you set the password on a stock DSL CD (like the account locked flag?). There are also two files that I'm not sure about (I think they DSL specific, maybe even just left over from the build process) /etc/passwd- and /etc/shadow-. I would try backing up all four files.
Posted by mikshaw on June 18 2005,14:51
/etc/shadow was the file, thanks. So far seems to be no problem restoring just this file.I don't use the backup/restore feature either, but i do use custom myDSL packages to do a similar kind of restoration. My new myDSL package now contains /opt/bootlocal.sh /etc/inittab /etc/shadow No remastering, no fiddling with settings during boot. Runlevel 5 is reached, including 4 terminals ready for login just like in all the other distros i've used. I wonder how it is that you helped me accomplish what was your own request, and you still have to do a work-around....I can't imagine how two people would get different results on the same system, unless there is a hardware limitation on your end, or maybe something was distorted during your remaster. I have yet to remaster, or even burn a recent CD, since the myDSL system + frugal provides me with as much flexibility as i need. Posted by tbielawa on June 18 2005,19:53
I just tested on another computer (this would be number 6), and a stock DSL 1.2.1 CD works as expected. Knoppix 3.4 (from which DSL 1.2.1 appears to be derived from) works fine on all of the computers. So something that was modified to create DSL 1.2.1 must be causing the problem only on some hardware (I’m thinking maybe a stripped down X server). I’m just going to start replacing things until I get it to work properly across the board, or irrecoverably break something ;).You might want to consider also replacing /.bash_profile with an empty file so you can log in as root in runlevel 5. The stock /.bash_profile will automatically log you in as DSL anytime you log in as root in runlevel 5. |