I don't seem to have any virtual desktops available after a fresh installation of F23 server edition. What am I missing?
On 02/24/2016 02:12 PM, CLOSE Dave wrote:
I don't seem to have any virtual desktops available after a fresh installation of F23 server edition. What am I missing?
Virtual desktops are normally a part of a GUI, which isn't part of the default installation for the server edition. Do you mean that you don't have the alternate text consoles that should be available?
On 02/24/16 02:45 PM, Joe Zeff wrote:
Virtual desktops are normally a part of a GUI, which isn't part of the default installation for the server edition. Do you mean that you don't have the alternate text consoles that should be available?
Yes. Sorry for the terminology confusion.
On Wed, 24 Feb 2016 14:12:58 -0800 CLOSE Dave Dave.Close@us.thalesgroup.com wrote:
I don't seem to have any virtual desktops available after a fresh installation of F23 server edition. What am I missing?
The virtual consoles are created by systemd at startup.
Do you have the following files on your system? /usr/lib/systemd/system-generators/systemd-getty-generator /usr/lib/systemd/system/console-getty.service /usr/lib/systemd/system/container-getty@.service /usr/lib/systemd/system/getty.target /usr/lib/systemd/system/getty@.service /usr/lib/systemd/system/multi-user.target.wants/getty.target /usr/share/man/man8/systemd-getty-generator.8.gz /etc/systemd/logind.conf
The last file contains the defaults that systemd uses when generating gettys.
$ cat /etc/systemd/logind.conf # This file is part of systemd. # # systemd is free software; you can redistribute it and/or modify it # under the terms of the GNU Lesser General Public License as published by # the Free Software Foundation; either version 2.1 of the License, or # (at your option) any later version. # # See logind.conf(5) for details
[Login] #NAutoVTs=6 #ReserveVT=6 #KillUserProcesses=no #KillOnlyUsers= #KillExcludeUsers=root #InhibitDelayMaxSec=5 #HandlePowerKey=poweroff #HandleSuspendKey=suspend #HandleHibernateKey=hibernate #HandleLidSwitch=suspend #HandleLidSwitchDocked=ignore #PowerKeyIgnoreInhibited=no #SuspendKeyIgnoreInhibited=no #HibernateKeyIgnoreInhibited=no #LidSwitchIgnoreInhibited=yes #IdleAction=ignore #IdleActionSec=30min #RuntimeDirectorySize=10% #RemoveIPC=yes
You could just do a dnf reinstall systemd on your system. Something must have gone really wrong for virtual consoles to be missing.
stan wrote:
I don't seem to have any virtual desktops available after a fresh installation of F23 server edition. What am I missing?
Do you have the following files on your system? /usr/lib/systemd/system-generators/systemd-getty-generator /usr/lib/systemd/system/console-getty.service /usr/lib/systemd/system/container-getty@.service /usr/lib/systemd/system/getty.target /usr/lib/systemd/system/getty@.service /usr/lib/systemd/system/multi-user.target.wants/getty.target /usr/share/man/man8/systemd-getty-generator.8.gz /etc/systemd/logind.conf
I have all those files, which are part of the systemd package.
The last file contains the defaults that systemd uses when generating gettys.
My file is identical to the default except,
NAutoVTs=6 # same as default ReserveVT=6 # same as default LidSwitchIgnoreInhibited=yes
You could just do a dnf reinstall systemd on your system. Something must have gone really wrong for virtual consoles to be missing.
Trying that soon.
On Thu, 25 Feb 2016 09:58:43 -0800 CLOSE Dave Dave.Close@us.thalesgroup.com wrote:
I have all those files, which are part of the systemd package.
Run systemctl -a -t service and search the output for tty. It's less, so /tty will do it. There should be a service running for each getty.
If there isn't, run journalctl -r and search the output for tty. The -r puts things in reverse order, so you will find the last mention of tty by the system. It is also less, so /tty will work. If something went wrong, this should tell you what.
stan wrote:
The last file contains the defaults that systemd uses when generating gettys.
My file is identical to the default except,
NAutoVTs=6 # same as default ReserveVT=6 # same as default LidSwitchIgnoreInhibited=yes
This doesn't seem to be a problem. Are you trying to reach the vconsoles from X, and not using Ctl-Alt-F[2-6]? i.e. is it plugged in? :-)
stan wrote:
Run systemctl -a -t service and search the output for tty. It's less, so /tty will do it. There should be a service running for each getty.
# systemctl -a -t service | grep tty getty@tty1.service loaded inactive dead Getty on tty1
If there isn't, run journalctl -r and search the output for tty. The -r puts things in reverse order, so you will find the last mention of tty by the system. It is also less, so /tty will work. If something went wrong, this should tell you what.
All lines since the last boot... (journalctl -r --no-pager | grep tty)
Feb 17 11:08:43 pses23top polkitd[740]: Registered Authentication Agent for unix-process:4254:7165877 (system bus name :1.5981 [/usr/bin/pkttyagent --notify-fd 5 --fallback], object path /org/freedesktop/PolicyKit1/AuthenticationAgent, locale en_US.UTF-8) Feb 16 15:14:27 pses23top kernel: 00:05: ttyS0 at I/O 0x3f8 (irq = 4, base_baud = 115200) is a 16550A Feb 16 15:14:27 pses23top kernel: 00:04: ttyS1 at I/O 0x2f8 (irq = 3, base_baud = 115200) is a 16550A Feb 16 15:14:27 pses23top kernel: console [tty0] enabled
On Thu, 25 Feb 2016 14:15:02 -0800 CLOSE Dave Dave.Close@us.thalesgroup.com wrote:
# systemctl -a -t service | grep tty getty@tty1.service loaded inactive dead Getty on tty1
This is from my system: getty@tty1.service loaded active running Getty on tty1 getty@tty2.service loaded active running Getty on tty2 getty@tty3.service loaded active running Getty on tty3 getty@tty4.service loaded active running Getty on tty4 getty@tty5.service loaded active running Getty on tty5 getty@tty6.service loaded active running Getty on tty6
All lines since the last boot... (journalctl -r --no-pager | grep tty)
Feb 17 11:08:43 pses23top polkitd[740]: Registered Authentication Agent for unix-process:4254:7165877 (system bus name :1.5981 [/usr/bin/pkttyagent --notify-fd 5 --fallback], object path /org/freedesktop/PolicyKit1/AuthenticationAgent, locale en_US.UTF-8) Feb 16 15:14:27 pses23top kernel: 00:05: ttyS0 at I/O 0x3f8 (irq = 4, base_baud = 115200) is a 16550A Feb 16 15:14:27 pses23top kernel: 00:04: ttyS1 at I/O 0x2f8 (irq = 3, base_baud = 115200) is a 16550A Feb 16 15:14:27 pses23top kernel: console [tty0] enabled
Here is an example of what happens on my system: Feb 25 14:29:13 localhost.localdomain systemd[1]: Started Getty on tty1. Feb 25 14:29:13 localhost.localdomain systemd[1]: Starting Getty on tty1... Feb 25 14:29:13 localhost.localdomain systemd[1]: Started Getty on tty6. Feb 25 14:29:13 localhost.localdomain systemd[1]: Starting Getty on tty6...
It looks like systemd is not even being invoked to set up ttys. That is what inactive dead means to me, anyway. Try, as root, systemctl unmask getty@tty1.service systemctl enable getty@tty1.service systemctl start getty@tty1.service
The @ might need to be escaped. If this doesn't do it, I'm out of ideas. Maybe someone else can point you in the right direction.
If this works for getty1, all the gettys should start at the next reboot (I think).
On 02/25/2016 03:46 PM, stan wrote:
On Thu, 25 Feb 2016 14:15:02 -0800 CLOSE Dave Dave.Close@us.thalesgroup.com wrote:
# systemctl -a -t service | grep tty getty@tty1.service loaded inactive dead Getty on tty1
This is from my system: getty@tty1.service loaded active running Getty on tty1 getty@tty2.service loaded active running Getty on tty2 getty@tty3.service loaded active running Getty on tty3 getty@tty4.service loaded active running Getty on tty4 getty@tty5.service loaded active running Getty on tty5 getty@tty6.service loaded active running Getty on tty6
All lines since the last boot... (journalctl -r --no-pager | grep tty)
Feb 17 11:08:43 pses23top polkitd[740]: Registered Authentication Agent for unix-process:4254:7165877 (system bus name :1.5981 [/usr/bin/pkttyagent --notify-fd 5 --fallback], object path /org/freedesktop/PolicyKit1/AuthenticationAgent, locale en_US.UTF-8) Feb 16 15:14:27 pses23top kernel: 00:05: ttyS0 at I/O 0x3f8 (irq = 4, base_baud = 115200) is a 16550A Feb 16 15:14:27 pses23top kernel: 00:04: ttyS1 at I/O 0x2f8 (irq = 3, base_baud = 115200) is a 16550A Feb 16 15:14:27 pses23top kernel: console [tty0] enabled
Here is an example of what happens on my system: Feb 25 14:29:13 localhost.localdomain systemd[1]: Started Getty on tty1. Feb 25 14:29:13 localhost.localdomain systemd[1]: Starting Getty on tty1... Feb 25 14:29:13 localhost.localdomain systemd[1]: Started Getty on tty6. Feb 25 14:29:13 localhost.localdomain systemd[1]: Starting Getty on tty6...
It looks like systemd is not even being invoked to set up ttys. That is what inactive dead means to me, anyway. Try, as root, systemctl unmask getty@tty1.service systemctl enable getty@tty1.service systemctl start getty@tty1.service
The @ might need to be escaped. If this doesn't do it, I'm out of ideas. Maybe someone else can point you in the right direction.
If this works for getty1, all the gettys should start at the next reboot (I think).
The getty@tty1.service is dead probably because the X server was started at some point, and that takes over tty1.
tty2-6 will not be started unless you try to use them (e.g. the getty on tty2 will only start if you use ALT-F2 from a console screen or CTRL-ALT-F2 from the desktop). Once they're started, however, they continue to run. ---------------------------------------------------------------------- - Rick Stevens, Systems Engineer, AllDigital ricks@alldigital.com - - AIM/Skype: therps2 ICQ: 226437340 Yahoo: origrps2 - - - - "You think that's tough? Try herding cats!" - ----------------------------------------------------------------------
Rick Stevens wrote:
tty2-6 will not be started unless you try to use them (e.g. the getty on tty2 will only start if you use ALT-F2 from a console screen or CTRL-ALT-F2 from the desktop). Once they're started, however, they continue to run.
I fully understand this. I now believe the problem is only indirectly related to virtual consoles. If I start the machine in multi-user mode (runlevel 3), the vconsoles work as expected. Only when running under X (via startx or graphical mode) do they fail.
So my vconsoles are properly configured and work correctly outside of X. While X is running, if I press CTRL-ALT-F2, for example, the F2 vconsole does not start and the X display remains. However, X is stuck; keyboard or mouse input does not work. Remote access via SSH continues to work but the console is effectively dead. If I logout of X (without trying to start any vconsole), the logout works but no login prompt appears. Again, the console is effectively dead.
I've also seen some possibly related issues. I generally configure X so that SHIFT-CTRL-TAB goes to the previous desktop. On F23, that combination is ignored. CTRL-TAB to go to the next desktop works. I also configure X so that a left mouse click outside any window should bring up an application launcher. Again, that input is ignored. Right and middle click actions work as expected. These problems occur even on systems where the vconsoles and logout work correctly. Those systems were upgraded to F23 rather than installed from scratch.
If it matters, all these systems are using KDE, not Gnome.
On 02/26/2016 02:47 PM, CLOSE Dave wrote:
Rick Stevens wrote:
tty2-6 will not be started unless you try to use them (e.g. the getty on tty2 will only start if you use ALT-F2 from a console screen or CTRL-ALT-F2 from the desktop). Once they're started, however, they continue to run.
I fully understand this. I now believe the problem is only indirectly related to virtual consoles. If I start the machine in multi-user mode (runlevel 3), the vconsoles work as expected. Only when running under X (via startx or graphical mode) do they fail.
So my vconsoles are properly configured and work correctly outside of X. While X is running, if I press CTRL-ALT-F2, for example, the F2 vconsole does not start and the X display remains. However, X is stuck; keyboard or mouse input does not work. Remote access via SSH continues to work but the console is effectively dead. If I logout of X (without trying to start any vconsole), the logout works but no login prompt appears. Again, the console is effectively dead.
Wow. Uhm, since ssh works, have you used it to crawl around in the logs to see if something weird is going on?
I've also seen some possibly related issues. I generally configure X so that SHIFT-CTRL-TAB goes to the previous desktop. On F23, that combination is ignored. CTRL-TAB to go to the next desktop works. I also configure X so that a left mouse click outside any window should bring up an application launcher. Again, that input is ignored. Right and middle click actions work as expected. These problems occur even on systems where the vconsoles and logout work correctly. Those systems were upgraded to F23 rather than installed from scratch.
If it matters, all these systems are using KDE, not Gnome.
Oh, Ok. I'm running Xfce myself on a machine that was upgraded F22->F23. Granted I'm using the default key bindings:
CTRL-ALT-HOME to go back one workspace CTRL-ALT-END to go forward one workspace CTRL-ALT-<F2...F6> to get the available virtual consoles
I have noticed, however, that CTRL-ALT-1 through CTRL-ALT-5 do NOT take me directly to the workspaces (I have five set up). I don't typically use that feature anyway, which is why I never noticed before.
Hmmmmmmmmm........ ---------------------------------------------------------------------- - Rick Stevens, Systems Engineer, AllDigital ricks@alldigital.com - - AIM/Skype: therps2 ICQ: 226437340 Yahoo: origrps2 - - - - I'm afraid my karma just ran over your dogma - ----------------------------------------------------------------------
Rick Stevens wrote:
So my vconsoles are properly configured and work correctly outside of X. While X is running, if I press CTRL-ALT-F2, for example, the F2 vconsole does not start and the X display remains. However, X is stuck; keyboard or mouse input does not work. Remote access via SSH continues to work but the console is effectively dead. If I logout of X (without trying to start any vconsole), the logout works but no login prompt appears. Again, the console is effectively dead.
Wow. Uhm, since ssh works, have you used it to crawl around in the logs to see if something weird is going on?
I have to correct my statement above. SSH does not work after this lock up and an active SSH session stops just like the console. After reboot, I can't find anything useful in the logs.
I wrote:
My file is identical to the default except,
NAutoVTs=6 # same as default ReserveVT=6 # same as default LidSwitchIgnoreInhibited=yes
Hit send to quickly. That last should be "LidSwitchIgnoreInhibited=no".