Bug#524666: installation-guide: Document the use of TERM= for serial consoles
Frans Pop, le Sun 19 Apr 2009 01:20:07 +0200, a écrit :
> On Sunday 19 April 2009, Samuel Thibault wrote:
> > That's already much better than only dumb emulation.
>
> AFAICT D-I only actually sets dumb for s390 (rootskel). Where do you see
> this and where does that come from?
That's only my memory of installing Etch on a machine over serial at
XenSource.
> if I boot an armel image over sercon from minicom I get TERM=vt102,
> which matches the minicom setting and thus seems to have a sane
> default.
It's a sane default indeed. As I try it again, it indeed provides quite
good terminal emulation, even arrows do work. I wonder why I wasn't
getting those with Etch.
> Though if I change minicom to use ansi, I still get vt102.
Yes, there is no standard way for a tty (here, minicom) to announce its
type.
> Adding the boot parameter TERM=ansi does change things a bit, but not
> enough to be called an improvement.
But conversely it could be needed if you weren't using an vt102/ansi
terminal, but a dumb terminal instead, in which case you'd want to to
force TERM to dumb to avoid ugly artifacts due to ansi escapes.
> > > That would at the very least need to be documented as well,
> >
> > Agreed.
>
> Please provide an improved proposed patch.
Here it is.
> > That makes using arrows & such work while with dumb emulation you are
> > mostly out of luck. IIRC that also makes non-ASCII characters work.
>
> When exactly is this needed? In which concrete cases would a user get what
> improvement?
The precise use case that made me look for the way to change TERM= was
the installation mentioned above.
> Is that actually important during an installation (keep in mind that a
> lot of sercon installs will switch to network-console pretty quickly
> anyway)?
"A lot" does not mean "all of them" :) In my case it was a lot simpler
to stay with the serial console.
> How will the *user* know that he can/should select a different TERM
> and which one to use?
In my case, the issue was "can", and that's what I wanted to document.
Whether and which TERM should be selected is quite another story. In the
patch attached to this mail I added some guidelines.
> Please provide more context than you're doing currently. This has to be
> useful for *regular* users, not only for users who already know they
> might need a different terminal type and how to set things up correctly
> on their host system and in their terminal emulator.
The bit that I was missing in my case was _how_ to change TERM, and at
that time it took me some time to realize that putting it on the command
line would pass it as an environment variable, while the installation
guide could as well just document it.
> If this is in fact specific to accessibility, then please document it as
> such.
I'm not _only_ working on accessibility stuff ;)
Samuel
Index: en/boot-installer/parameters.xml
===================================================================
--- en/boot-installer/parameters.xml (révision 58263)
+++ en/boot-installer/parameters.xml (copie de travail)
@@ -53,7 +53,18 @@
<userinput>console=<replaceable>device</replaceable></userinput>
argument to the kernel, where <replaceable>device</replaceable> is
your serial device, which is usually something like
-<filename>ttyS0</filename>.
+<filename>ttyS0</filename>. To fix the console output, you may
+additionally append
+<userinput>TERM=<replaceable>type</replaceable></userinput> where
+<replaceable>type</replaceable> is the <quote>terminfo</quote>
+name of the terminal emulation supported by the serial console.
+Only <userinput>linux</userinput>, <userinput>vt102</userinput>,
+<userinput>ansi</userinput>, <userinput>bterm</userinput>,
+and <userinput>dumb</userinput> are supported. While
+<userinput>vt102</userinput> is generally a safe bet for a lot of
+kinds of serial consoles, specifying <userinput>ansi</userinput> may
+avoid a few display artifacts, and at worse <userinput>dumb</userinput>
+should be usable in any case.
</para><para arch="sparc">
Reply to: