[syslinux] garbage on serial console after pxelinux.0 is loaded

Gene Cumm gene.cumm at gmail.com
Tue Apr 10 06:51:48 PDT 2018

On Thu, Apr 5, 2018 at 10:20 AM, Scheie, Peter M via Syslinux
<syslinux at zytor.com> wrote:
> -----Original Message-----
> From: hpa at zytor.com [mailto:hpa at zytor.com]
> Sent: Wednesday, April 04, 2018 4:26 PM
> To: Scheie, Peter M
> Subject: RE: [syslinux] garbage on serial console after pxelinux.0 is loaded
> On April 4, 2018 2:08:12 PM PDT, "Scheie, Peter M" <Petre.Scheie at gd-ms.com> wrote:
>>-----Original Message-----
>>From: Syslinux [mailto:syslinux-bounces at zytor.com] On Behalf Of H.
>>Peter Anvin via Syslinux
>>Sent: Wednesday, April 04, 2018 1:54 PM
>>To: syslinux at zytor.com
>>Subject: Re: [syslinux] garbage on serial console after pxelinux.0 is
>>On 03/05/18 12:17, Scheie, Peter M via Syslinux wrote:
>>> A little more info:
>>> I was mistaken in saying that the garbage on the screen doesn't
>>interfere with typed commands/stanzas; it does.  If I can type the name
>>of a stanza and hit enter quickly enough before the garbage is spat to
>>the screen, it seems to start loading a kernel, but then it aborts.
>>> And the garbage appears to be varying quantities of '[0n', as in
>>sometimes there will be one instance of that in the string spit out,
>>and sometimes there will be a dozen, or any quantity in between.
>>Sometimes it's all just blank spaces; and sometimes, as mentioned,
>>there are fragments of text that was previously displayed.
>>> Any ideas as to what [0n is?  Some sort of screen formatting?
>>Yes, that's an attribute code <ESC>[0m.  Most likely you have BIOS
>>serial redirection *and* Syslinux serial port enabled at the same time.
>>       -hpa
>>Syslinux mailing list
>>Submissions to Syslinux at zytor.com
>>Unsubscribe or set options at:
>>Ah, yes, of course.  Disabling it in the 'default' menu file fixed the
>>issue.  Well, sort of.  The real problem is we have a few different
>>hardware platforms.  Some have a built-in DisplayPort, which we don't
>>use, while others do not.  The SERIAL setting in 'default' is for those
>>systems that don't have a DP.  Those systems with DP default to having
>>their console redirected to COM1 (ttyS0) which is what we connect to.
>>But as you pointed out, having the serial port setting in both places
>>causes problems.
>>If we take the SERIAL setting out, those machines w/o DP appear to load
>>pxelinux.0 but don't display anything.  However, they still respond to
>>keyboard input, as we have stanzas in 'default' that use pxechain.com
>>to redirect them to other PXE servers.  That suggests that we could
>>have a stanza in 'default' that simply redirects to the same PXE server
>>but to a different menu file, e.g., default.serial.  Is that possible?
> Yes, that works.
> --
> I setup a stanza that points to a submenu, i.e., a menu from a separate file, thusly:
> MENU LABEL DisplayPort
> KERNEL vesamenu.c32
> APPEND dpmenu.cfg
> So, when this stanza is selected, is vesamenu.c32 reloaded with new menu arguments?  dpmenu.cfg is just a copy of 'default' but without the SERIAL settings.  But when I bootup one of the machines that has DP and try to choose 'm', I get a "Initial menu has no LABEL entries" error.  The first line in 'default' is
> DEFAULT vesamenu.c32
> so that's also the first line in dpmenu.cfg; is that a problem?  Is it necessary, since the 'm' stanza called vesamenu.c32 with dpmenu.cfg as an APPEND?
> Petre

1) If present, always put the SERIAL directive on the first line to
ensure early processing.

2) DEFAULT should point to a LABEL to prevent some of the other warnings.

3) UI should be used to call vesamenu.c32/menu.c32 instead of DEFAULT.

4) What does dpmenu.cfg look like?  It sounds like there's other
errors.  Perhaps Mac line-end instead of Unix?  Looking back at
Syslinux-2.00's syslinux.doc (text), it would seem any version with
pxechain.com should be fine with Unix and DOS line ends.


More information about the Syslinux mailing list