You don't need DHCPD for network booting! bootpd and NFS is
*all* you need.

The timeout on bootpd requests should be far longer than
the response time of even a slow machine. I always use tcpdump
when I feel like things are stuck somewhere.

-Gunther

Brian Chase wrote:

> On Tue, 29 Jan 2002, Matthew Sell wrote:
> 
> 
>>The machine that handles DHCP is kinda slow - so it may not be
>>responding quickly enough for an address request. Sound logical? I
>>probably should move that functionality to a faster machine, or use
>>RARP. Does that sound like a logical next step?
>>
> 
> It could be that the machine is slow.  You might consider running your
> dhcpd with verbose debugging, just to make sure that the VAX is talking
> with it.  Another point brought up by someone is the difficulty which
> occasionally arises from ethernet switches not properly forwarding
> BOOTP, DHCP, or RARP requests to all the ports.
> 
> If you are using a switch, and your DHCP server doesn't see a request
> coming in from the VAX, then, if possible, see if you can move the VAX
> and the DHCP server onto the same ethernet segment.  Either hook them up
> with a strand of thin-net cable, or put them both on an ethernet hub.
> If all you have 10Base-T and no access to a simple hub, then you could
> also make a cross-over cable to run directly between the transceiver on
> the VAX and to the NIC in your DHCP server.  There's always a half-dozen
> ways to work around these sort of problems-- unfortunately, many of
> them are kind of inconvenient.
> 
> You might go ahead an set a static arp entry on the system running the
> DHCP server that contains the VAX'es HW ethernet address.  And be sure
> that your DHCP server's entry for the VAX client is laid out like it
> should be.  Here's an example of the /etc/dhcpd.conf I used on my
> NetBSD/i386 1.4.2 system that ran the DHCP server:
> 
> ----------------------8<---------------------------
> 
> use-host-decl-names on;
> server-name "nfsserver";
> option domain-name "mydomain.com";
> option domain-name-servers 192.168.1.2;
> 
> subnet 192.168.1.0 netmask 255.255.255.0 {
>   next-server 192.168.1.10;
>   option subnet-mask 255.255.255.0;
>   option broadcast-address 192.168.1.255;
>   option routers 192.168.1.1;
> }
> 
> host vaxclient {
>   hardware ethernet 08:00:2b:a1:b2:c3;
>   fixed-address 192.168.1.100;
>   option root-path "/export/vaxclient";
>   option host-name "vaxclient";
> }
> 
> ----------------------8<---------------------------
> 
> 
>>Probably a good addition for the bootloader would be added status
>>messages......
>>
> 
> The lack of messages is probably, or at least in part, due to the
> relatively small space you're allowed to cram all the functionality of
> bootloader into.  I forget what the exact MOP load specs are for the
> MicroVAX-II and the VAXstation 2000, but I think it only guarantees
> that you'll have a chunk of 64KB into which you can put fit bootloader.
> I think later models expanded that to 256KB.  In practice, you can
> usually throw in a lot more than the spec allows for, which is what the
> VAX/Linux guys have been doing by loading the whole kernel with MOP.
> 
> Most of the useful debugging details can be deduced from what you are,
> or in many cases "aren't", seeing on the server side.
> 
> -brian.
> 


-- 
Gunther Schadow, M.D., Ph.D.                    gschadow@regenstrief.org
Medical Information Scientist      Regenstrief Institute for Health Care
Adjunct Assistant Professor        Indiana University School of Medicine
tel:1(317)630-7960                         http://aurora.regenstrief.org