Date: Tue, 22 Jan 2002 16:52:10 +0100 (MET) From: Vahe Khachikyan <vahe@fh-konstanz.de> To: freebsd-alpha@freebsd.org Subject: Fwd: Re: Is anybody actually able to netboot at the moment? Message-ID: <1011714730.3c4d8aaabc447@vvl15.fh-konstanz.de>
next in thread | raw e-mail | index | archive | help
----- Forwarded message from Vahe Khachikyan <vahe@fh-konstanz.de> ----- Date: Tue, 22 Jan 2002 16:13:22 +0100 (MET) From: Vahe Khachikyan <vahe@fh-konstanz.de> Reply-To: Vahe Khachikyan <vahe@fh-konstanz.de> Subject: Re: Is anybody actually able to netboot at the moment? To: Andrew Gallatin <gallatin@cs.duke.edu> Hi, on my AS 200 I get another problem. The part with BOOTP is ok. It looks like the SRM correctly assigns the IP address, ,netmask etc.then loads the image... At this point after Image is loaded I always get ..bootstrap failure. I have tried to do the same procedure , with firmware update image, still the same result. Whether kernel.flp nor the firmware update image wants to boot:-( -- Vahe --- Quoting Andrew Gallatin <gallatin@cs.duke.edu>: > > Peter Wemm writes: > > By netboot, I mean having something like ewa0_protocols = BOOTP and > > 'boot ewa0' (or ewb0 in some of my cases).. ? > > > > And if so, how are you doing it? I've been fighting with a group > of > > cranky PWS 500au's (MIATAs) on a (fairly high powered) switch. > > > > If I run a tcpdump on the machine running dhcpd, I see about (maybe) > one in > > 50 broadcast bootp (or dhcp discover) packets actually arriving. > However, > > when net_open() switches to RARP, I see every single one of those > arrive. > > Sometimes even SRM fails to have its bootp broadcasts seen and has > to > > retry. Most of the times when the server actually sees the query > and > > replies, the reply isn't seen by the client. However, the tftp > downloads > > and rarp/arp broadcasts seem 100% reliable. > > > > Eventually, if I am lucky, the client will actually get a response to > the > > packets it sends and will magically snap into life, and fire up the > NFS > > root mount etc. > > > > The only holdup seems to be the dhcp query.. :-( > > <..> > > I seem to remember finding a problem in libstand quite some time ago, > but never having time to track it down. I think that it had to do > with checksum calculations for recv'ed packets. Try turning off UDP > checksums on the dhcp server & see if that improves matters. > > > Anyway.. the final straw is that when it finally does get up to a > loader > > 'ok' prompt, doing a "load kernel" causes a 'kernel stack not > valid' > > trap back to SRM. (doh!) > > That's a new one! Does it actually start loading the kernel? (as > verified by tcpdump) > > Doug sent me a patch which helps to debug loader crashes last year. > I posted it to the list & its archived here: > > http://docs.FreeBSD.org/cgi/getmsg.cgi?fetch=18451+0+archive/2001/freebsd- alpha/20010603.freebsd-alpha > > > Can anybody please sanity check this for me? On several different > > combinations of hardware if possible. > > Unfortunately, I'm no longer in a position to play with this... I > wish you'd been interested a year ago :-( > > Drew > > > To Unsubscribe: send mail to majordomo@FreeBSD.org > with "unsubscribe freebsd-alpha" in the body of the message > > ----- End forwarded message ----- To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-alpha" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?1011714730.3c4d8aaabc447>