Hello Dan,
Dan Farrell <[EMAIL PROTECTED]> writes:
> I was going to suggest you avoid pxegrub, but I guess you figured that
> out for yourself.
>
>>
>> I'm almost certain to get stuck so I'll
>> probably be back asking again.
>
> Let me know.
Well, I had it working on Friday but over the weeekend I tinkered some
more with pixegrub and broke it again. Now pxelinux won't work
either.
I have the following dhcpd.conf on the host (192.168.0.2):
+dhcpd.conf++++++++++++++++++++++++++++++++++++++++++++
ddns-update-style none ;
next-server 192.168.0.2;
option domain-name-servers 192.168.0.2;
option routers 192.168.0.2;
option space PXE;
option PXE.mtftp-ip code 1 = ip-address;
option PXE.mtftp-cport code 2 = unsigned integer 16;
option PXE.mtftp-sport code 3 = unsigned integer 16;
option PXE.mtftp-tmout code 4 = unsigned integer 8;
option PXE.mtftp-delay code 5 = unsigned integer 8;
option PXE.discovery-control code 6 = unsigned integer 8;
option PXE.discovery-mcast-addr code 7 = ip-address;
# Declare the subnet where our diskless nodes will live
subnet 192.168.0.0 netmask 255.255.255.0 {
# Provide PXE clients with appropriate information
class "pxeclient" {
match if substring(option vendor-class-identifier, 0, 9) = "PXEClient";
vendor-option-space PXE;
# At least one of the vendor-specific PXE options must be set in
# order for the client boot ROMs to realize that we are a PXE-compliant
# server. We set the MCAST IP address to 0.0.0.0 to tell the boot ROM
# that we can't provide multicast TFTP.
option PXE.mtftp-ip 0.0.0.0;
}
host cctp {
hardware ethernet 00:01:03:ce:52:a8;
fixed-address 192.168.0.3;
# option option-150 "/calcite/boot/grub.lst";
filename "pxelinux.0";
}
}
allow bootp;
allow booting;
+++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
I have the following in.tftp on the host (192.168.0.2):
+in.tftpd++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
# /etc/init.d/in.tftpd
INTFTPD_PATH="/diskless"
INTFTPD_USER="nobody"
INTFTPD_OPTS="-v -s ${INTFTPD_PATH}"
+++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
I have bzImage, pxelinux.0 and pxelinux.cfg/ in /diskless on the
host. pxelinux.cfg/ contains a default file with these contents:
+pxelinux.cfg/default+++++++++++++++++++++++++++++++++++++++++++++++++
DEFAULT /bzImage
APPEND ip=dhcp root=/dev/nfs nfsroot=192.168.0.2:/diskless/calcite
++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
When I try to boot the client, tcpdump -i eth1 prints the following
dialogue:
tcpdump -i eth1
tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on eth1, link-type EN10MB (Ethernet), capture size 96 bytes
11:50:39.930039 IP 0.0.0.0.bootpc > 255.255.255.255.bootps: BOOTP/DHCP, Request
from 00:01:03:ce:52:a8 (oui Unknown), length 548
11:50:39.930886 IP lowalbite.private.bootps > 255.255.255.255.bootpc:
BOOTP/DHCP, Reply, length 300
11:50:42.072242 IP 0.0.0.0.bootpc > 255.255.255.255.bootps: BOOTP/DHCP, Request
from 00:01:03:ce:52:a8 (oui Unknown), length 548
11:50:42.073040 IP lowalbite.private.bootps > 255.255.255.255.bootpc:
BOOTP/DHCP, Reply, length 300
11:50:42.077032 arp who-has lowalbite.private tell calcite.private
11:50:42.077088 arp reply lowalbite.private is-at 00:04:75:77:98:4f (oui
Unknown)
11:50:42.077165 IP calcite.private.2070 > lowalbite.private.tftp: 27 RRQ
"pxelinux.0" octet tsize 0
11:50:42.080043 IP lowalbite.private.32771 > calcite.private.2070: UDP, length
36
11:50:42.081409 IP calcite.private.2071 > lowalbite.private.tftp: 32 RRQ
"pxelinux.0" octet blksize 1456
11:50:42.084147 IP lowalbite.private.32771 > calcite.private.2071: UDP, length
36
11:50:47.077314 arp who-has calcite.private tell lowalbite.private
11:50:48.077397 arp who-has calcite.private tell lowalbite.private
11:50:49.077484 arp who-has calcite.private tell lowalbite.private
If I connect a terminal to the client I see:
"Non-system disk or disk error replace and strike any key when ready"
> By the way, if you're looking for performance enhancements to your
> diskless hosts, let me know. I have found some, and am also always
> looking for more.
Right now I'd be happy to have it working, no matter how slowly.
One think I have found by searching the internet is that pxegrub has
history of poor interaction with 3Com cards, which is what I'm using.
Thanks for any help you can offer.
Roger
--
[EMAIL PROTECTED] mailing list
