Output turns into blinking prompt after selecting nonexistent tty but only when using xdm

[BS:D]

Hi All,

I don't know if this is the right area to post this question but not sure where else I would post it, I am new to this forum, this is my first post

When using the default /etc/ttys config and trying to change to the nonexistent ttyv9 (Ctrl+Alt+F10) It gives me a black screen with a blinking prompt, I can no longer change to a different tty including the ttyv8 used for xdm, but can still reboot FreeBSD by pressing Ctrl+Alt+Del

After editing /etc/ttys I found this happens with any amount of ttys set and always when trying to select any nonexistent tty after the tty used for xdm.

Just wondering why this happens and if I have not configured FreeBSD right to use a GUI, I found a work around as well which I posted at the bottom.

Any help would be much appreciated, below is some info on my current machine where the issue is happening -


FreeBSD
12.0-RELEASE-p10
Generic Kernel
Using ZFS


/etc/ttys -

ttyv0 "/usr/libexec/getty Pc" xterm onifexists secure
# Virtual terminals
ttyv1 "/usr/libexec/getty Pc" xterm onifexists secure
ttyv2 "/usr/libexec/getty Pc" xterm onifexists secure
ttyv3 "/usr/libexec/getty Pc" xterm onifexists secure
ttyv4 "/usr/libexec/getty Pc" xterm onifexists secure
ttyv5 "/usr/libexec/getty Pc" xterm onifexists secure
ttyv6 "/usr/libexec/getty Pc" xterm onifexists secure
ttyv7 "/usr/libexec/getty Pc" xterm onifexists secure
ttyv8 "/usr/local/bin/xdm -nodaemon" xterm onifexists secure

Installed on the machine (using pkg install) -

openbox-3.6_5
obconf-2.0.4_2
obmenu-1.0.8
xorg-minimal-7.5.2_2
xdm-1.1.12


The only config file I made was a .xsession ASCII text file inside the users home directory which is used to log in using a GUI, /home/user/.xsession -
/usr/local/bin/openbox-session


/etc/rc.conf -
xdm_enable="YES"
moused_enable="NO"


The work around I did was in /etc/ttys by setting ttyv7 to use xdm. Alternatively setting ttyv9 seems to work as well. This seemed to stop the issue.

/etc/ttys -

ttyv0 "/usr/libexec/getty Pc" xterm onifexists secure
# Virtual terminals
ttyv1 "/usr/libexec/getty Pc" xterm onifexists secure
ttyv2 "/usr/libexec/getty Pc" xterm onifexists secure
ttyv3 "/usr/libexec/getty Pc" xterm onifexists secure
ttyv4 "/usr/libexec/getty Pc" xterm onifexists secure
ttyv5 "/usr/libexec/getty Pc" xterm onifexists secure
ttyv6 "/usr/libexec/getty Pc" xterm onifexists secure
ttyv7 "/usr/local/bin/xdm -nodaemon" xterm onifexists secure
ttyv8 "/usr/libexec/getty Pc" xterm onifexists secure

Thanks for taking the time to read my post

 

[gpw928]

Hi,

I just plugged a physical FreeBSD system into a display, and I can confirm that the behaviour you describe is "normal", at least for FreeBSD 12.0.

I'm not sure that I'd sweat on it too much. You are, after all, asking to switch keyboard control to a non-existent virtual terminal.

Having handed control to something that does not exist, you might expect a small amount of ongoing bother...

You can recover, by logging in elsewhere (as root) and sending signal 15 to the xdm process with the highest PID, e.g.

[sherman.131] $ ps -auxw | grep xdm | grep -v grep
root   1401   0.0  0.0  14080   3424  -  I    29Aug19      0:00.01 /usr/local/bin/xdm -nodaemon ttyv8
root  79640   0.0  0.9 172116 152032  -  Ss   11:07        0:02.61 /usr/local/bin/X :0 -auth /var/db/xdm/authdir/authfiles/A:0-vbli
root  79765   0.0  0.1  19164   9316  -  Is   11:10        0:00.05 xdm: :0 (xdm)
[sherman.132] $ sudo kill -15 79765

That brings the keyboard control back to the virtual terminal associated with (a newly spawned) xdm.

There may be better solutions, but my knowledge of keyboard management is limited...