[syslinux] pxelinux problem
Eric P. McCoy
ctr2sprt at cox.net
Wed Jul 17 12:53:43 PDT 2002
"H. Peter Anvin" <hpa at zytor.com> writes:
> > Note that it's not trying to load the kernel image at all. It did
> > occur to me that this might be one of the tftpd-related problems
> > mentioned in the docs, but unfortunately, the docs are extremely thin
> > on what non-Linux tftpds _do_ work correctly (presumably because you
> > don't know).
> 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.
> > 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?
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()?
> > 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).
--
Eric McCoy (reverse "ten.xoc at mpe", mail to "ctr2sprt" is filtered)
"Last I checked, it wasn't the power cord for the Clue Generator that
was sticking up your ass." - John Novak, rasfwrj
More information about the Syslinux
mailing list