Thanks for your response,

> 1. Do you have logging of the TFTP server, too ?  Does the client
>    actually download the kernel and initrd by TFTP ?

I just turned it on (-v verbose flag to tftpd, as provided by Red Hat).  I
get:

Jul  7 21:52:41  in.tftpd[20388]: RRQ from 127.0.0.1 filename pxelinux.bin
Jul  7 17:53:19  dhcpd: DHCPDISCOVER from 00:02:55:c7:05:b6 via eth2
Jul  7 17:53:19  dhcpd: DHCPOFFER on 192.168.0.161 to 00:02:55:c7:05:b6 via eth2
Jul  7 17:53:20  dhcpd: DHCPREQUEST for 192.168.0.161 (192.168.0.168) from 
00:02:55:c7:05:b6 via eth2
Jul  7 17:53:20  dhcpd: DHCPACK on 192.168.0.161 to 00:02:55:c7:05:b6 via eth2
Jul  7 21:53:20  in.tftpd[20434]: RRQ from 192.168.0.161 filename /pxelinux.bin
Jul  7 21:53:20  in.tftpd[20434]: tftp: client does not accept options
Jul  7 21:53:20  in.tftpd[20435]: RRQ from 192.168.0.161 filename /pxelinux.bin
Jul  7 21:53:20  in.tftpd[20436]: RRQ from 192.168.0.161 filename 
/pxelinux.cfg/01-00-02-55-c7-05-b6
Jul  7 21:53:20  in.tftpd[20436]: sending NAK (1, File not found) to 
192.168.0.161
Jul  7 21:53:20  in.tftpd[20437]: RRQ from 192.168.0.161 filename 
/pxelinux.cfg/C0A800A1
Jul  7 21:53:20  in.tftpd[20438]: RRQ from 192.168.0.161 filename /message.txt
Jul  7 21:53:25  in.tftpd[20439]: RRQ from 192.168.0.161 filename /kernel
Jul  7 21:53:25  in.tftpd[20440]: RRQ from 192.168.0.161 filename /initrd.img

[hostname removed manually] So, it's pulling those files (which do exist, and
load successfully manually).  The C0A800A1 is the syslinux.cfg that is copied
there by si_mkbootserver, and it contains the systemimager boot option (which
is set as the default).

After that, another DHCPDISCOVER, OFFER, REQUEST, ACK (same IP address), then
BusyBox starts up, klogd, kernel startup, then the broadcast DHCPDISCOVER.

> 2. Does the DHCP server log the DHCP broadcasts both from PXE,
>    and later as well when the kernel is booting on the client ?

No, PXE shows "normal" DHCP as you can see above.  Broadcast is only when
kernel is booting on client.

> 3. You mention device eth1: Are you sure that this is the
>    correct network that is connected to the server (seems there
>    should be an eth0 as well).  Are you sure that the client's
>    PXE actually works on eth1, and not only on eth0 ?  Maybe
>    this is a BIOS option ?

BIOS has only planar ethernet 1 PXE turned on.  I'm not sure if that's
supposed to be eth0.  If so, how do I get BusyBox to use eth0 instead of
eth1?

> 4. You could verify your server's setup with a completely
>    different PC, which would then point to the trouble being
>    on the x330 client...

I'll try that last as it's a remote location.

> 5. You could set up your DHCP server so that it gives leases
>    to any MAC-address requesting an IP-address (no "deny
>    unknown-clients;"), and then assign an IP-range to such clients.
>    Would tell you if you had the wrong MAC-address.

I've included dhcpd.conf below, as you can see I don't have "deny
unknown-clients;" set.

Regards,
Dan W.


Here's dhcpd.conf (all uncommented lines).  Pretty much all of it was written
as is by si_mkdhcpserver.  I added the fixed-address stanza for the
particular node.

        authoritative;
        ddns-update-style none;
        option option-140 code 140 = text;
        option option-141 code 141 = unsigned integer 32;
        option option-142 code 142 = string;
        option option-143 code 143 = string;
        option option-144 code 144 = string;
        option option-140 "192.168.0.168";
        option option-144 "n";
        next-server 192.168.0.168;
        option log-servers 192.168.0.168;
        default-lease-time -1;
        filename "/pxelinux.bin";   # i386
        shared-network eth2 {
          subnet 192.168.0.0 netmask 255.255.255.0 {
            range  192.168.0.161 192.168.0.166;
            option subnet-mask 255.255.255.0;
            option broadcast-address 192.168.0.255;
            option domain-name "genomics.internal";
              host test1 {
                        hardware ethernet 00:02:55:C7:05:B6;
                        fixed-address 192.168.0.161;
              }
          }
        }

Regards,
Dan W.


-------------------------------------------------------
This SF.Net email is sponsored by the 'Do More With Dual!' webinar happening
July 14 at 8am PDT/11am EDT. We invite you to explore the latest in dual
core and dual graphics technology at this free one hour event hosted by HP,
AMD, and NVIDIA.  To register visit http://www.hp.com/go/dualwebinar
_______________________________________________
Sisuite-users mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/sisuite-users

Reply via email to