QubesOS
On first use, DispVM console has strange control character sequences preloaded into the `login:` prompt, causing the first authentication attempt to fail
Qubes OS release
R4.3
Brief summary
When using the "Open console in qube" feature of Qube Manager to open a DispVM console for a qube, the character sequence ^[[24;1R^[[24;80R^[[24;1R^[[24;80R is pre-populated in the login: prompt. If I ignore this weird sequence of characters, enter the username user, and press Enter, I immediately get the message Authentication failure. A new login prompt then appears that doesn't have this weird sequence preloaded into it. Typing user into that prompt and pressing Enter results in a successful login. I can also use Backspace to erase most of the character sequence, then type user and press Enter to log in successfully the first time.
Steps to reproduce
- In Qube Manager, click any qube (doesn't seem to matter which, I can reproduce this on a Fedora 42 AppVM, a Whonix-Workstation 18 AppVM, and the debian-13-xfce template), click "Start/Resume", then click "Open console in qube".
- Look at the
login:prompt before attempting to log in. - Type
userand press Enter. - After the authentication failure, type
useragain and press Enter. - Shut down the qube.
- In Qube Manager, click any qube, then click "Start/Resume", then click "Open console in qube".
- When the
login:prompt occurs, press and hold Backspace until as many characters as you can erase are erased. - Type
userand press Enter.
Expected behavior
No character sequence should be preloaded into the login: prompt. Typing user and pressing Enter should work to log in the first time.
Actual behavior
The character sequence mentioned previously is preloaded into the login: prompt. Typing user and pressing Enter fails the first time but works the second time. When trying to erase the character sequence, it is possible to erase most of it, but not the entirety of it. Despite this, typing user and pressing Enter after erasing as much of the sequence as possible still works to log in.
Additional information
n/a
I investigate this a bit, it happens on the first connection to a qube, not on subsequent ones. Rebooting might trigger it again (didn't do it).
From XTerm control sequences:
CSI ? Ps n
Device Status Report (DSR, DEC-specific).
Ps = 6 ⇒ Report Cursor Position (DECXCPR). The response
[row;column] is returned as
CSI ? r ; c R
(assumes the default page, i.e., "1").
CSI Ps n Device Status Report (DSR).
Ps = 5 ⇒ Status Report.
Result ("OK") is CSI 0 n
Ps = 6 ⇒ Report Cursor Position (CPR) [row;column].
Result is CSI r ; c R
Note: it is possible for this sequence to be sent by a
function key. For example, with the default keyboard
configuration the shifted F3 key may send (with shift-,
control-, alt-modifiers)
CSI 1 ; 2 R , or
CSI 1 ; 5 R , or
CSI 1 ; 6 R , etc.
The second parameter encodes the modifiers; values range from
2 to 16. See the section PC-Style Function Keys for the
codes. The modifyFunctionKeys and modifyKeyboard resources
can change the form of the string sent from the modified F3
key.
If you want to debug this, try testing with different XTerm versions on the template for default-mgmt-dvm. 80x24 is the geometry passed with qubes.ShowInTerminal RPC. I hope that some option for socat can avoid this.
I have also experienced this, thought this was just a weird thing with some configuration of mine, but it seems not.
The characters are as follows (so the exact same as in the OP):
Also affects qvm-console. It is easier to test with that tool. Changing to Xfce terminal does not help, probably because it uses the same underlying library.
For additional information on the garbled text on dispvm console: the same string also appears in a Debian-13 based VM under Qubes OS 4.2.4.
