[syslinux] Re: Stumped

[Peter Caldes]

"H. Peter Anvin" wrote:

> Peter Caldes wrote:
> >
> > I too have this problem (2.0.6) where you get the 'boot:' prompt, you type
> > the label of the kernel you want to use and when you hit 'ENTER' nothing
> > happens.
> >
> > If you don't type an option/label and hit ENTER, it boots the default
> > image.
> > However I have found if that you do NOT hit enter relatively quickly after
> > you see the boot: prompt, then nothing happens and you can't even get the
> > default image to boot.
> >
> > My hardware is a blade server which has NO video card. Just a serial port.
> > The BIOS on my server does console redirection to the serial port and stops
> > the console redirection as soon as the OS starts running. I have noticed
> > that console redirection is still active while pxelinux.0 is running while
> > it displays the boot: prompt. You can tell redirection is active because it
> > constantly refreshes the ENTIRE screen which is verry slow at 9600 :-(
> >
> > I had a 'SERIAL' option defined in my PXELINUX config file and at first I
> > thought PXELINUX was getting confused because it was trying to access both
> > the serial port AND the console but the console was really being mapped by
> > the BIOS to the serial port. However I still had the problem when I
> > commented out the SERIAL option.
> >
> > I haven't had time to try any other version of PXELINUX to see if something
> > else works.
> >
> > To the developers: Please let me know what I can provide you to help debug
> > this.
> >
>
> This sounds like it's getting some kind of input from the serial port
> and it's getting confused.
>
> Please *remove* (not comment out - just in case the parser's broken) the
> SERIAL option and see what happens.
>
> There really seems to be a lot of weirdness going on on machines with no
> video card.  Some of that weirdness is possible to work around, but not
> all of it.
>
>         -hpa

I think I may have found part of the problem but need to research some more.
I am using pxelinux.0 from syslinux 2.06.
For TFTPD I am using tftp-hpa-0.34 and it is stared via INETD as follows:
    tftp    dgram   udp     wait    root    /usr/sbin/in.tftpd in.tftpd -vv -t 60
-s /tftpboot

When I typed a label at the PXELINUX's 'boot:' prompt and hit ENTER, the cursor
does not move and it seems to be ignoring the ENTER key. However, a sniffer trace
shows it is trying to TFTP the kernel from my TFTPD server so it is not ignoring
my ENTER key but seems to be too busy to respond.

The pxelinux client issues a RRQ to the TFTP server with the options TSIZE=0 and
BLKSIZE=1440.
The server replies with an Option Acknowledgement (OACK) containing TSIZE=1031498
and BLKSIZE=1440.
However the client then issues another RRQ request for the same file to the
server.

I looked at RFC2347 and the client is supposed to send an ACK(block=0) to the
server before the server starts sending the data.

The trace then shows the server responding with another OACK for the 2nd RRQ and
rexmits the OACK for the initial request. The client then issues another RRQ
which the TFTP server responds with an OACK and also re-xmit's the OACK's for the
first two RRQ's.
It repeats this until it has issued 6 RRQ's and repeats the process 3 more times
using the suffixes ".cbt", ".0" and ".com".

Here are the tftpd log messages, with the IP address slightly mangled:

Nov 10 23:53:08 VUSLAB02 in.tftpd[17990]: RRQ from xxx.72.96.221 filename
/PXEClient/bootcd-linux
Nov 10 23:53:09 VUSLAB02 in.tftpd[17991]: RRQ from xxx.72.96.221 filename
/PXEClient/bootcd-linux
Nov 10 23:53:10 VUSLAB02 in.tftpd[17992]: RRQ from xxx.72.96.221 filename
/PXEClient/bootcd-linux
Nov 10 23:53:13 VUSLAB02 in.tftpd[17993]: RRQ from xxx.72.96.221 filename
/PXEClient/bootcd-linux
Nov 10 23:53:18 VUSLAB02 in.tftpd[17996]: RRQ from xxx.72.96.221 filename
/PXEClient/bootcd-linux
Nov 10 23:53:29 VUSLAB02 in.tftpd[17997]: RRQ from xxx.72.96.221 filename
/PXEClient/bootcd-linux
Nov 10 23:53:50 VUSLAB02 in.tftpd[17999]: RRQ from xxx.72.96.221 filename
/PXEClient/bootcd-linux.cbt
Nov 10 23:53:51 VUSLAB02 in.tftpd[18000]: RRQ from xxx.72.96.221 filename
/PXEClient/bootcd-linux.cbt
Nov 10 23:53:52 VUSLAB02 in.tftpd[18001]: RRQ from xxx.72.96.221 filename
/PXEClient/bootcd-linux.cbt
Nov 10 23:53:55 VUSLAB02 in.tftpd[18002]: RRQ from xxx.72.96.221 filename
/PXEClient/bootcd-linux.cbt
Nov 10 23:54:00 VUSLAB02 in.tftpd[18003]: RRQ from xxx.72.96.221 filename
/PXEClient/bootcd-linux.cbt
Nov 10 23:54:10 VUSLAB02 in.tftpd[18004]: RRQ from xxx.72.96.221 filename
/PXEClient/bootcd-linux.cbt
Nov 10 23:54:31 VUSLAB02 in.tftpd[18006]: RRQ from xxx.72.96.221 filename
/PXEClient/bootcd-linux.0
Nov 10 23:54:32 VUSLAB02 in.tftpd[18007]: RRQ from xxx.72.96.221 filename
/PXEClient/bootcd-linux.0
Nov 10 23:54:33 VUSLAB02 in.tftpd[18008]: RRQ from xxx.72.96.221 filename
/PXEClient/bootcd-linux.0
Nov 10 23:54:36 VUSLAB02 in.tftpd[18009]: RRQ from xxx.72.96.221 filename
/PXEClient/bootcd-linux.0
Nov 10 23:54:41 VUSLAB02 in.tftpd[18010]: RRQ from xxx.72.96.221 filename
/PXEClient/bootcd-linux.0
Nov 10 23:54:52 VUSLAB02 in.tftpd[18011]: RRQ from xxx.72.96.221 filename
/PXEClient/bootcd-linux.0
Nov 10 23:55:13 VUSLAB02 in.tftpd[18012]: RRQ from xxx.72.96.221 filename
/PXEClient/bootcd-linux.com
Nov 10 23:55:14 VUSLAB02 in.tftpd[18013]: RRQ from xxx.72.96.221 filename
/PXEClient/bootcd-linux.com
Nov 10 23:55:15 VUSLAB02 in.tftpd[18014]: RRQ from xxx.72.96.221 filename
/PXEClient/bootcd-linux.com
Nov 10 23:55:18 VUSLAB02 in.tftpd[18015]: RRQ from xxx.72.96.221 filename
/PXEClient/bootcd-linux.com
Nov 10 23:55:23 VUSLAB02 in.tftpd[18016]: RRQ from xxx.72.96.221 filename
/PXEClient/bootcd-linux.com
Nov 10 23:55:33 VUSLAB02 in.tftpd[18017]: RRQ from xxx.72.96.221 filename
/PXEClient/bootcd-linux.com

I'll try using 2.07-pre1 tomorrow but I diffed the sources and don't see any
changes relating to TFTP so I am not hopeful.
I will also try using the '-r blksize' on the tftpd-hpa server to see if that
makes a difference.
This is long enuf as it is so I won't attach the sniffer trace output.