Hi Timothy, Timothy Sample writes: > I have a lead now! At least, I have a way to stop GDM and return to a > working TTY. Assuming that you are working on a TTY with elogind > session “c1”, you can run > > herd stop xorg-server & (sleep 5; loginctl activate c1) > > When GDM exits, it leaves the display in a non-working state. It turns > out elogind knows how to fix this. I’m guessing it does some magic with > the VT_* set of ioctl requests (see “src/basic/terminal-util.c” from > elogind). I’m not sure how to get GDM to clean up after itself, though. > It might be expecting things of elogind that it doesn’t provide (since > it is not exactly like the original logind from systemd). Thanks for investigating! My first guess is that when GDM is killed, it's leaving the keyboard in RAW mode. Running "kbd_mode -a" might be another way to recover. "Alt + SysRq + r" might be another way. I'll try again after I finish building my post-staging-merge system. https://www.tldp.org/HOWTO/Keyboard-and-Console-HOWTO-9.html I notice that in Debian's start script for gdm3, it runs activate_logind just before launching GDM, where activate_logind is the following Bash function: activate_logind() { # Try to dbus activate logind to avoid a race conditions if we are not # running systemd as PID1 and we have systemd << 204 package installed (see: # #747292) if [ ! -d /run/systemd/system ] && [ -x /lib/systemd/systemd-logind-launch ]; then dbus-send --system --print-reply --dest=org.freedesktop.DBus /org/freedesktop/DBus \ org.freedesktop.DBus.StartServiceByName string:org.freedesktop.login1 uint32:0 2>&1 > /dev/null fi } The Debian start script is debian/gdm3.init in . The Debian bug referenced above is . Might be worth a try, but admittedly I'm grasping at straws here :) Mark