Didn't know exactly which forum to post.

Does anyone know if it's possible to change the LISH console size?

I have my window size for PuTTY set to 120x60 and yet still only get an 80x20 (I think, I'd have to count columns and rows to be sure) window. I've noticed the same size restriction for the LISH console in a terminal window on Ubuntu.

Makes for reading some text files while configuring everything a little hard.

This is a limitation of how we communicate with your Linode. The resize requests are correctly processed by our host server, but there is no way to resize hvc0 -- think of it as a serial console. You can't resize a serial console either.

It annoys me too, and I'm studying it to see if there's a workaround.

_________________
Disclaimer: I am no longer employed by Linode; opinions are my own alone.

Oh well
I'll live
with it
for now

Have you tried telling the system once you have the shell about your new size? It seems to work fine for me although since the serial port is essentially always connected it doesn't reset on each connection.

As Jed's response mentions, the console is essentially a raw serial port, always connected to the host LISH process, or at least to its screen instance, which while the port itself has no natural size, the "terminal" on the other end does - the terminal in this case is your client. So you've got this extra fairly low level interface in between your putty client and the system (unlike a direct ssh connection).

For example, if I open up a 180x40 terminal window (I'm on OSX at the moment, so Terminal is my emulator rather than putty, but it shouldn't matter), and ssh to LISH for my Linode (Ubuntu 8.04) and then login, initially it continues to use whatever the serial port was last set to (defaulting on bootup to 80x24 (or 25)). But if I tell it the right size it adjusts properly, e.g.:

> stty cols 180 rows 40
> stty -a
speed 38400 baud; rows 40; columns 180; line = 0;
(...)

and after that, that console port is 180x40 and tools should work fine, from simple wrapping of "ls" to full-screen stuff like vi/emacs. As a serial port setting, it also appears to retain itself across connections, so you'd have to adjust again if you came in with a different sized window.

It's actually possible with some terminal emulation types to interrogate the terminal/emulator - the resize utility can do this with xterm, though its use has become much less common over time with increased automatic detection of changes (sigwinch & terminal size ioctls), which tools like ssh can propagate across network connections. But even older vt100 emulation has escape sequences that can determine the size if you have a utility/code to perform query.

I think Putty may actually support the xterm escape sequence (at least my copy has an option to disable it), so you might be able to use resize if you have it installed. On Debian/Ubuntu it's part of packages like xterm so if you don't have much in the way of X client support you get a bunch of unnecessary stuff just to get resize, so it might not be worth it.

Another workaround would be to check your current tty in a login script, setting an appropriate default size when coming in on a real tty (like /dev/tty1) versus a network connection which generally gets a pty (like /dev/pts/0).

-- David

That's pretty solid. I forgot all about stty. Now, as for passing SIGWINCH...

_________________
Disclaimer: I am no longer employed by Linode; opinions are my own alone.

Heh, yeah, with today's interfaces it's easy to forget all the support that exists for terminals over serial lines.

I don't think you've got much room to work with the serial console. Unless you're going to require the VPS itself to run a custom getty or equivalent on the console port that will parse special commands from LISH to identify the terminal size. Even if there's an OOB way to generate signals from xen to a guest domain (I'm not that familiar with xen), you'd still need something running in the guest domain to handle that signal within the context of the console.

All in all, probably not worth the complexity.

-- David