[syslinux] pxelinux problem
H. Peter Anvin
hpa at zytor.com
Wed Jul 17 12:59:11 PDT 2002
Eric P. McCoy wrote:
>
>>What gave you the impression that they were "Linux" tftpds? tftp-hpa,
>>in particular, should run on anything vaguely Unixlike.
>
> *shrug* It wasn't in the FreeBSD ports collection, and most software
> that runs on FreeBSD is in there somewhere. But tftp-hpa does indeed
> compile and run fine.
>
Good. Want to put it in there? :)
>
>>>Since my boot server runs FreeBSD, I'm afraid I can't
>>>use either of the options the docs mention as being known to work
>>>correctly. My choices appear to be yale-tftpd-3.0 (the one I'm using
>>>now) and utftpd-0.2.4. The man page says nothing on the subject
>>>(blocksize and such), and I don't know how else I would find out if my
>>>tftpd supports it. It seems like a hard reset with no error message
>>>and no delay (regardless of what I say in the configuration file) is
>>>pretty extreme for an error condition anyway, which makes me think
>>>this might be a bug of some kind.
>>
>
>>That is somewhat odd, yes. It shouldn't do that.
>
> Switching to tftp-hpa solved the problem, so evidently it was some bug
> in the tftpd I was using. But might I suggest a more useful error
> message than just a hard reboot?
>
There is something more fundamentally bizarre going on. Normal
behaviour is that it prints an error message, waits 5 minutes, then
reboot (otherwise an unattended machine might be waiting forever due to
a temporary server failure.) I'm guessing the BIOS clock on your
machine is broken somehow, and that those "5 minutes" take no time at all.
>
> Oh, and as a tangential note because I notice your name is remarkably
> similar to that of the author of tftp-hpa, the command line seems to
> interpret everything after the first `directory' as a directory. The
> following won't work but (IMO) should:
>
> in.tftpd -s sandbox -u user
>
> It bails complaining of too many directories. I'm a little surprised
> getopt() doesn't handle the above correctly; is it an artifact of
> using a non-glibc getopt()?
>
Actually, this is according to the POSIX specification for getopt(),
which glibc deliberately do not follow unless you set the environment
variable POSIXLY_CORRECT. This affects all programs that use getopt()
and is beyond my control.
>
>>>Regarding hardware compatibility and possible brokenness, I have an
>>>eepro100+ with the onboard PXE boot ROM version 0.99. It actually
>>>works quite well with the FreeBSD pxeboot image, but I'd rather go
>>>back to Linux.
>>
>
>>Those early PXE boot ROMs are buggy as hell. If this is a standalone
>>card (as opposed to something on the motherboard) I would immediately
>>upgrade it to the latest version from Intel.
>
> Upgraing NIC firmware on diskless machines is a nontrivial task, hence
> my reluctance to do so. It would involve taking out the NIC, putting
> it in a machine with a floppy drive or Windows, and then hoping the
> flash applies to this particular NIC (it's a Compaq-branded eepro100,
> so it may be just different enough to fsck up the ROM).
>
If it's working now, then it's not such a big deal. However, instead of
pulling out the NIC, since you apparently have pxelinux working, you
could use memdisk.
-hpa
More information about the Syslinux
mailing list