[SOLVED] Serial Devices Added to Debian/Ubuntu Guests: Default Settings are 80 column with reduced colors. Can we change this?

[SInisterPisces]

That might not have been as clear on (e-)paper as it sounded in my head. I've added a serial device to a Debian VM and configured the VM to use it as a terminal via serial-getty. I'm able to interact with the VM via the web-based xterm.js, so that's all working.

However, I"m not quite getting the output I want. The Debian defaults appear to be enforcing a strict 80 column width (I used nano to figure out how many characters wide my display was). I've attached a picture below.

Is there something I can modify in the .service file for the ttyS0-based serial-getty service to overcome this? I see that I can do things like tell it what sort of terminal to emulate, but I'm too unfamiliar with terminal standards to know what to do with that, and googling has been challenging as once you start googling terminal standards everyone seems to think you have an actual VT100 in your bedroom and want to make it do stuff.



EDIT: I still need to test it, but it looks like getting this into your bashrc is the answer.
See: https://unix.stackexchange.com/questions/16578/resizable-serial-console-window/680244#680244

EDIT 2: There was a typo in that last IF statement. It needed double-brackets for some reason.

EDIT 3: I can confirm that when added to /etc/bashrc.bash (the global .bashrc), the code below fixes the issue.
Of course, this doesn't do anything for the lack of color vs. an SSH terminal or the standard NoVNC interface, but that's not really an issue so much as a lack of tweaking on my end.

# resize function for connected serial console
resize() {
  old=$(stty -g)
  stty raw -echo min 0 time 5

  printf '\0337\033[r\033[999;999H\033[6n\0338' > /dev/tty
  IFS='[;R' read -r _ rows cols _ < /dev/tty

  stty "$old"

  #echo "cols:$cols"
  #echo "rows:$rows"
  stty cols "$cols" rows "$rows"
}

ALL_COMMANDS_FINISHED=1

PreCommands() {
  if [ "$ALL_COMMANDS_FINISHED" = '1' ]; then
    ALL_COMMANDS_FINISHED=0
    resize
    #echo "1->0"
  fi
}

PostCommands() {
  ALL_COMMANDS_FINISHED=1
}
 
# if login thru tty*
if [[ $(tty) = /dev/tty* ]]; then
  # PreCommands is called before every single command on a command line
  trap PreCommands DEBUG
  # PostCommands is called after all commands on a command line are finished
  PROMPT_COMMAND="PostCommands"
fi

 

[LnxBil]

Thank you for providing the above bash snippet to fix things. Best to drop it in a file in /etc/profile.d in order to be easily distributable.

EDIT 2: There was a typo in that last IF statement. It needed double-brackets for some reason.

Yes, it's a special pattern matching that ordinary [ does not support. [[ is the bash enhanced if syntax, which allows more patterns.

Of course, this doesn't do anything for the lack of color vs. an SSH terminal or the standard NoVNC interface, but that's not really an issue so much as a lack of tweaking on my end.

That depends on the terminal. The default serial terminal is:

$ echo $TERM
vt220

If you add resetting the terminal to your script, it will show colors:

export TERM=screen-256color

 

[LnxBil]

I have to say, I don't like the delay it introduces between the end of the command and printing the prompt. Normally, I don't resize the windows that often, so I changed it to manual execution after initial login.

 

[SInisterPisces]

Thank you for providing the above bash snippet to fix things. Best to drop it in a file in /etc/profile.d in order to be easily distributable.


Yes, it's a special pattern matching that ordinary [ does not support. [[ is the bash enhanced if syntax, which allows more patterns.


That depends on the terminal. The default serial terminal is:

$ echo $TERM
vt220

If you add resetting the terminal to your script, it will show colors:

export TERM=screen-256color

I really appreciate the explanation of how that all worked, and the term variable. I'll have to try that tomorrow. I figured I needed to tell it to report itself as something else, but I wasn't sure what.

I have to say, I don't like the delay it introduces between the end of the command and printing the prompt. Normally, I don't resize the windows that often, so I changed it to manual execution after initial login.

Okay, good, that's not just a performance glitch on my end. I noticed that, too. It's awful.
I have 96 GiB of RAM in this machine, so it's not resource starved. Is this a possible bug I should report, or just a slow emulated serial driver? (I might report it either way.)

I also noticed that there's no key repeat? I've used plenty of real serial hardware interfaces with minicom and a serial cable and never run into that.
(That is, hold a key down. It doesn't just keep repeating. It fires off once.)

 

[LnxBil]

I have 96 GiB of RAM in this machine, so it's not resource starved. Is this a possible bug I should report, or just a slow emulated serial driver? (I might report it either way.)

No, that's just the time it takes to run the commands to get the terminal parameters EVERY time you render the prompt. Therefore you normally don't run stuff PROMPT_COMMAND exactly because of the slowliness. The explanation in the SO thread you copied the code from states, that the program renders every character in the line until it reaches its end and therefore known how long a line is. The same is true for the lines, so it has to detect this every time, which is very time consuming. I also tried the SIGWENCH path, which is not rendered via serial, only with a real terminal. That would have been the best option.

I also noticed that there's no key repeat? I've used plenty of real serial hardware interfaces with minicom and a serial cable and never run into that.
(That is, hold a key down. It doesn't just keep repeating. It fires off once.)

Oh, I haven't tried that, yet.

 

[SInisterPisces]

No, that's just the time it takes to run the commands to get the terminal parameters EVERY time you render the prompt. Therefore you normally don't run stuff PROMPT_COMMAND exactly because of the slowliness. The explanation in the SO thread you copied the code from states, that the program renders every character in the line until it reaches its end and therefore known how long a line is. The same is true for the lines, so it has to detect this every time, which is very time consuming. I also tried the SIGWENCH path, which is not rendered via serial, only with a real terminal. That would have been the best option.

That makes perfect sense and also makes this feel less like a solution and more like a kludge.

It seems like it should be possible to tell getty what width to use instead of forcing it to the desired width on every rendering of the prompt?

 

[BobhWasatch]

Window size can change and serial terminals don't have a standard way to communicate that. SSH does which is why you don't see the problem there.

 

[LnxBil]

It seems like it should be possible to tell getty what width to use instead of forcing it to the desired width on every rendering of the prompt?

You can just set COLUMNS and ROWS accordingly, despite what actual setup you have. That's what the stty cols rows does.

This is what I use now:

# serial terminal resize on bash login or via function resize_terminal_size
# https://unix.stackexchange.com/questions/16578/resizable-serial-console-window

# only run for serial terminals and interactive bash prompts
if [ "${BASH_VERSION-}" != "" ] && [ "${PS1-}" != "" ] && [[ "$(tty)" =~ "/dev/tty"* ]]
then

 # resize function for connected serial console
 resize_terminal_size() {
   old=$(stty -g)
   stty raw -echo min 0 time 5

   printf '\0337\033[r\033[999;999H\033[6n\0338' > /dev/tty
   IFS='[;R' read -r _ rows cols _ < /dev/tty

   stty "$old"

   stty cols "$cols" rows "$rows"
 }

 resize_terminal_size

 export TERM=screen-256color
fi

It sets the resolution once on login and if you change the window afterwards, I just call resize_terminal_size.