[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [Xen-users] hvm pxe boot - tftp fails to transfer files larger than 2 blocks
The tftp transfer is only transferring the first 2 blocks of the request file. I'm running tftpd-hpa on the server side and xen 4.0.1-rc3-pre with 2.6.32x pv-ops on the client side. At first I was stuck here: [PXE]Hunting for pixies...found !PXE at 0009ce60...ok configfile: (nd)/import/tools/pxe/kaan-22-dpm/menu.lst bootp called in PXE TFTP mode dhcp called in PXE TFTP mode I ran wireshark on dom0 with a capture filter for the domU's MAC. It showed that the menu.lst was not being completely transfered. Only the first half, which were mostly comments were making onto the wire. Stripping out all the comments got me as far as a grub menu: GNU GRUB version 0.97-os.6 (626K lower / 3143300K upper memory) +-------------------------------------------------------------------[0]---+ | kernel /import/bedge/root/boot/vmlinu> | | initrd /import/bedge/root/boot/initrd> | | | | | | | | | | | | | | | | | | | | | +-------------------------------------------------------------------------+ Press 'b' to boot, 'e' to edit the selected command in the boot sequence, 'c' for a command-line, 'o' to open a new line after ('O' for before) the selected line, 'd' to remove the selected line, '/?nN' to search, or escape to go back to the main menu. Then when the boot started, the same problem with the file transfer happened, 2 blocks and then nothing. Wireshark shows that the tftp client, the domU, never sends more than 2 Acks, so the tftp server keeps sending the 3rd packet and eventually gives up. This is the same behavior with the menu.lst file. which I was able to shorten to fit into 2 blocks, and in the kernel, which I cannot. One last clue that may or may not have anything to do with this is that after the transfer has time out, the tftp server starts sending our ARP requests for the domU. Does anyone have any suggestions? Should I try chainloading gPXE ad http boot? Or, is there some other way to transfer the kernel for an hvm domU? Here's the complete wireshark trace for the failed kernel transfer: 268 31.190226 kaan-22-dpm.lsi.com wlvdev.lsi.com TFTP Read Request, File: import/bedge/root/boot/vmlinuz-2.6.32.15\000, Transfer type: octet\000 269 31.198000 wlvdev.lsi.com kaan-22-dpm.lsi.com TFTP Option Acknowledgement 270 31.198278 kaan-22-dpm.lsi.com wlvdev.lsi.com TFTP Acknowledgement, Block: 0 271 31.198524 wlvdev.lsi.com kaan-22-dpm.lsi.com TFTP Data Packet, Block: 1 272 31.198809 kaan-22-dpm.lsi.com wlvdev.lsi.com TFTP Acknowledgement, Block: 1 <- this is the last ack sent, so there is no more data from the server. 273 31.201631 wlvdev.lsi.com kaan-22-dpm.lsi.com TFTP Data Packet, Block: 2 274 31.937849 wlvdev.lsi.com kaan-22-dpm.lsi.com TFTP Data Packet, Block: 1 275 32.197838 wlvdev.lsi.com kaan-22-dpm.lsi.com TFTP Data Packet, Block: 2 276 33.141874 wlvdev.lsi.com kaan-22-dpm.lsi.com TFTP Data Packet, Block: 1 (last) 277 33.937870 wlvdev.lsi.com kaan-22-dpm.lsi.com TFTP Data Packet, Block: 1 278 34.197800 wlvdev.lsi.com kaan-22-dpm.lsi.com TFTP Data Packet, Block: 2 279 37.937912 wlvdev.lsi.com kaan-22-dpm.lsi.com TFTP Data Packet, Block: 1 280 38.197905 wlvdev.lsi.com kaan-22-dpm.lsi.com TFTP Data Packet, Block: 2 281 45.937950 wlvdev.lsi.com kaan-22-dpm.lsi.com TFTP Data Packet, Block: 1 282 46.197921 wlvdev.lsi.com kaan-22-dpm.lsi.com TFTP Data Packet, Block: 2 283 61.938034 wlvdev.lsi.com kaan-22-dpm.lsi.com TFTP Data Packet, Block: 1 284 62.198076 wlvdev.lsi.com kaan-22-dpm.lsi.com TFTP Data Packet, Block: 2 285 66.937967 135.149.78.198 kaan-22-dpm.lsi.com ARP Who has 135.149.77.123? Tell 135.149.78.198 286 67.937945 135.149.78.198 kaan-22-dpm.lsi.com ARP Who has 135.149.77.123? Tell 135.149.78.198 287 68.937940 135.149.78.198 kaan-22-dpm.lsi.com ARP Who has 135.149.77.123? Tell 135.149.78.198 -Bruce _______________________________________________ Xen-users mailing list Xen-users@xxxxxxxxxxxxxxxxxxx http://lists.xensource.com/xen-users
|
Lists.xenproject.org is hosted with RackSpace, monitoring our |