From: David Isaacson on Friday, July 08, 2005 2:41 PM > > Hi again, > > I added some -vvv flags to tftp, this is what I got on the server in > /var/log/messages > > Jul 8 14:36:21 hepfs03 dhcpd: DHCPOFFER on 192.168.0.2 to > 00:e0:81:23:4e:b0 via eth1
Um, er, hmmm. I guest it was there :-/ > Jul 8 21:36:37 hepfs03 in.tftpd[7439]: RRQ from 192.168.0.2 filename > pxelinux.0 FWIW, this is the PXE boot loader going down to the node. It's responsible for everything else until the kernel runs. > Jul 8 21:36:37 hepfs03 in.tftpd[7440]: RRQ from 192.168.0.2 filename > pxelinux.cfg/01-00-e0-81-23-4e-b0 > Jul 8 21:36:37 hepfs03 in.tftpd[7440]: sending NAK (1, File not found) > to 192.168.0.2 Here, pxelinux.0 is looking for a config file, starting with the one-and-only-for-this-node's-IP. This is the new human-readable format. > Jul 8 21:36:37 hepfs03 in.tftpd[7441]: RRQ from 192.168.0.2 filename > pxelinux.cfg/C0A80002 Again, looking for a config file specific to the node's IP in the old format, which is just the IPV4 address written as a 32-bit hex number. It then starts looking for more and more general config files by truncating digits from the IP, allowing you use per-IP, per-subnet, per-whatever config files. > Jul 8 21:36:37 hepfs03 in.tftpd[7449]: RRQ from 192.168.0.2 filename > pxelinux.cfg/default And it finally finds the default config file > Jul 8 21:36:37 hepfs03 in.tftpd[7450]: RRQ from 192.168.0.2 filename > message.txt > Jul 8 21:36:37 hepfs03 in.tftpd[7450]: sending NAK (1, File not found) > to 192.168.0.2 The [missing] optional boot message > Jul 8 21:36:42 hepfs03 in.tftpd[7451]: RRQ from 192.168.0.2 filename > kernel here's the kernel going down the wire > Jul 8 21:36:43 hepfs03 in.tftpd[7453]: RRQ from 192.168.0.2 filename > initrd.img and the initrd > All of this happens right at the start of the booting process. The > missing files really are missing, and the files it finds really are > there. As it should be. After the initrd goes down, the kernel starts on the client node, doing the usual kernel boot until it gets to the initrd at which point it becomes very SystemImager specific. As I mentioned in an earlier email, the rcS and functions scripts in the initrd take over. > There are no messages *at all* after this... OK, so that pretty much implicates the client node, otherwise you would have seen more DHCP messages when the node's dhclient ran. Now I'm back to wondering about that floppy light... It should turn off as soon as the kernel has satisfied itself a floppy isn't actually present. Questions, I have questions: Have you tried another client node? Do you see any messages about the NIC driver loading? What board do you have? > I don't really know > where to go from here... but I have to say I'm impressed with the amount > of help I've been getting ; ) Service with a :-) -- dnl My comments represent my opinions, not those of Intel Corporation. ------------------------------------------------------- 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 _______________________________________________ Oscar-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/oscar-devel
