[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [cobalt-developers] Qube3 bootp boot



Andy Brown wrote:

> Hi,
>
> I'm trying to setup a custom bootp server for Qube3's so that when a
> Qube is restored, it talks to our bootp server, which does the OS
> restore as per the CD, but it also applies all the up-to-date patches,
> because I've added them to the correct location on the machines HDD.
>
> For some reason though bootp seems to be failing, the bootp machine
> shows:
> Apr 11 10:38:16 tester dhcpd: BOOTREQUEST from 0:10:e0:4:cf:76 via eth1
> Apr 11 10:38:16 tester dhcpd: BOOTREPLY on 10.0.0.150 to 0:10:e0:4:cf:76
> via eth1
> Which looks correct apart from it requesting/replying quite a few times
> over and over, the errors shown on the console of the Qube3:
>
> Sending BOOTP requests ... timed out!
> IP-Config: Retrying forever (NFS root)...
> eth0: speed=100 duplex=full link=up
> eth1: Warning PHY setup did not complete. Check cable.
> Sending BOOTP requests ..
>
> Which continues on forever it seems.
>
> Is there something I'm missing, is the Qube checking something else when
> it received the bootp and not allowing the request?
>
> Any help would be gratefully accepted!

Andy,

    You may need to add the following route in your routing table to allow
broadcast packets to be sent out the ethernet port that you have the bootp
server on:

    /sbin/route add -net 255.255.255.255 netmask 255.255.255.255 eth<x>
(where x is the port you want the bootreplys going)

I suspect your bootp replys aren't getting out of the machine you have the
bootp server on, so even though the log indicates that the dhcp server is
trying to send a reply, it may not be getting there.  You can put a 3rd
machine on the wire and use the "tcpdump" command to listen for packets on
the wire and see if the reply really is getting out of the machine.
However, I think if you just add the route, it may start to work.

- Lyle