On 21.09.2015 12:06, Gene Cumm wrote:> On Mon, Sep 21, 2015 at 2:38 AM, Mathias Radtke <m.radtke at uib.de> wrote: >> >> On 18.09.2015 16:35, Gene Cumm wrote: >>> 1) This is actually a critical cusp size. Watch what tftpd you use or >>> you'll never get it all. The tftpd needs to support rollover. >>> Consider HTTP as it should be more capable and much faster. >> The used TFTPD works fine with BIOS machines. >> I have two Initrd images. One is 64bit and almost 90MB and the 32bit is >> 85MB. >> I know that some tftpd have limitations and I use one of these. I am aware >> of the problem. > What's the exact file size in bytes? I presume you've done BIOS boots > with your 64-bit kernel/initrd and those succeed?Yes booting with a BIOS machine works fine for both architectures. Here's the size: 87146093 miniroot-20150917.bz2 91362629 miniroot-x64-20150917.bz2> Have you considered HTTP transfer?Currently not as we are bound to the currently used tftp.> What do you observe? Does it transfer the file then the Linux kernel > crashes? Does it spontaneously reboot before completing the > operation?The client is a VSphere VM Client. It displayes the IP Address and then: Loading Kernel..... ok Loading initrd.bz2... This stalls for minutes and the client reboots afterwards.> Have you tried doing a packet capture to see how far this client progresses? > > What tftpd? Have you reviewed the logs for partial transfers?atftpd here's the syslog output. Sep 21 12:28:47 exp-srv-001 atftpd[5286]: Serving linux/syslinux64.efi to 192.168.10.174:1921 Sep 21 12:28:47 exp-srv-001 atftpd[5286]: Serving linux/ldlinux.e64 to 192.168.10.174:1922 Sep 21 12:28:47 exp-srv-001 atftpd[5286]: Serving linux/pxelinux.cfg/564dc8d7-26e8-7620-4dc0-5819d41c2e3a to 192.168.10.174:1923 Sep 21 12:28:47 exp-srv-001 atftpd[5286]: Serving linux/pxelinux.cfg/01-00-0c-29-1c-2e-3a to 192.168.10.174:1924 Sep 21 12:28:47 exp-srv-001 atftpd[5286]: Serving linux/pxelinux.cfg/C0A80AAE to 192.168.10.174:1925 Sep 21 12:28:47 exp-srv-001 atftpd[5286]: Serving linux/pxelinux.cfg/C0A80AA to 192.168.10.174:1926 Sep 21 12:28:47 exp-srv-001 atftpd[5286]: Serving linux/pxelinux.cfg/C0A80A to 192.168.10.174:1927 Sep 21 12:28:47 exp-srv-001 atftpd[5286]: Serving linux/pxelinux.cfg/C0A80 to 192.168.10.174:1928 Sep 21 12:28:47 exp-srv-001 atftpd[5286]: Serving linux/pxelinux.cfg/C0A8 to 192.168.10.174:1929 Sep 21 12:28:47 exp-srv-001 atftpd[5286]: Serving linux/pxelinux.cfg/C0A to 192.168.10.174:1930 Sep 21 12:28:47 exp-srv-001 atftpd[5286]: Serving linux/pxelinux.cfg/C0 to 192.168.10.174:1931 Sep 21 12:28:47 exp-srv-001 atftpd[5286]: Serving linux/pxelinux.cfg/C to 192.168.10.174:1932 Sep 21 12:28:47 exp-srv-001 atftpd[5286]: Serving linux/pxelinux.cfg/default to 192.168.10.174:1933 Sep 21 12:28:47 exp-srv-001 atftpd[5286]: Serving linux/vesamenu.c32 to 192.168.10.174:1934 Sep 21 12:28:47 exp-srv-001 atftpd[5286]: Serving linux/libcom32.c32 to 192.168.10.174:1935 Sep 21 12:28:47 exp-srv-001 atftpd[5286]: Serving linux/libutil.c32 to 192.168.10.174:1936 Sep 21 12:28:48 exp-srv-001 atftpd[5286]: Serving linux/pxelinux.cfg/default to 192.168.10.174:1937 Sep 21 12:28:49 exp-srv-001 atftpd[5286]: Serving linux/install-x64 to 192.168.10.174:1938 Sep 21 12:28:58 exp-srv-001 atftpd[5286]: Serving linux/miniroot-x64.bz2 to 192.168.10.174:1939 The .c32 files transfered are EFI64 files. I just copied them into the root directory for testing purposes. As soon as the images load I will organize the structure properly -- Mathias Radtke, uib mail m.radtke at uib.de
On Mon, Sep 21, 2015 at 6:36 AM, Mathias Radtke <m.radtke at uib.de> wrote:> On 21.09.2015 12:06, Gene Cumm wrote: >> >> On Mon, Sep 21, 2015 at 2:38 AM, Mathias Radtke <m.radtke at uib.de> wrote:>>> The used TFTPD works fine with BIOS machines. >>> I have two Initrd images. One is 64bit and almost 90MB and the 32bit is >>> 85MB. >>> I know that some tftpd have limitations and I use one of these. I am >>> aware >>> of the problem. >> >> What's the exact file size in bytes? I presume you've done BIOS boots >> with your 64-bit kernel/initrd and those succeed? > > Yes booting with a BIOS machine works fine for both architectures. > Here's the size: > 87146093 miniroot-20150917.bz2 > 91362629 miniroot-x64-20150917.bz2Thanks for the confirmation.>> Have you considered HTTP transfer? > > Currently not as we are bound to the currently used tftp.Adding DHCP option 210, forcibly or inside DHCP option 43 vendor-options, could redirect Syslinux to grab ldlinux.e64 and later files over HTTP.>> What do you observe? Does it transfer the file then the Linux kernel >> crashes? Does it spontaneously reboot before completing the >> operation? > > The client is a VSphere VM Client. > It displayes the IP Address and then: > Loading Kernel..... ok > Loading initrd.bz2... > > This stalls for minutes and the client reboots afterwards.Been there. I don't know if it's specific to the VMware-based VMs or not, yet. It keeps slowing down its responses, eventually getting a lot of retransmissions in the loop and then hits the 5-minute timeout mark and spontaneously reboots.>> Have you tried doing a packet capture to see how far this client >> progresses?Probably no need to do a packet capture as I've seen this myself and moved to HTTP. HTTP transfer beat out any of my TFTP transfers and was quite successful.>> What tftpd? Have you reviewed the logs for partial transfers? > > atftpd > here's the syslog output...snip> The .c32 files transfered are EFI64 files. I just copied them into the root > directory for testing purposes. As soon as the images load I will organize > the structure properlyI could have asked what version but since you've finally described the symptoms sufficiently, I'm already aware it won't matter. -- -Gene
On 21.09.2015 12:57, Gene Cumm wrote:> On Mon, Sep 21, 2015 at 6:36 AM, Mathias Radtke <m.radtke at uib.de> wrote: > >> On 21.09.2015 12:06, Gene Cumm wrote: >>> On Mon, Sep 21, 2015 at 2:38 AM, Mathias Radtke <m.radtke at uib.de> wrote: >>>> The used TFTPD works fine with BIOS machines. >>>> I have two Initrd images. One is 64bit and almost 90MB and the 32bit is >>>> 85MB. >>>> I know that some tftpd have limitations and I use one of these. I am >>>> aware >>>> of the problem. >>> What's the exact file size in bytes? I presume you've done BIOS boots >>> with your 64-bit kernel/initrd and those succeed? >> Yes booting with a BIOS machine works fine for both architectures. >> Here's the size: >> 87146093 miniroot-20150917.bz2 >> 91362629 miniroot-x64-20150917.bz2 > Thanks for the confirmation. > >>> Have you considered HTTP transfer? >> Currently not as we are bound to the currently used tftp. > Adding DHCP option 210, forcibly or inside DHCP option 43 > vendor-options, could redirect Syslinux to grab ldlinux.e64 and later > files over HTTP. > >>> What do you observe? Does it transfer the file then the Linux kernel >>> crashes? Does it spontaneously reboot before completing the >>> operation? >> The client is a VSphere VM Client. >> It displayes the IP Address and then: >> Loading Kernel..... ok >> Loading initrd.bz2... >> >> This stalls for minutes and the client reboots afterwards. > Been there. I don't know if it's specific to the VMware-based VMs or > not, yet. It keeps slowing down its responses, eventually getting a > lot of retransmissions in the loop and then hits the 5-minute timeout > mark and spontaneously reboots. > >>> Have you tried doing a packet capture to see how far this client >>> progresses? > Probably no need to do a packet capture as I've seen this myself and > moved to HTTP. HTTP transfer beat out any of my TFTP transfers and > was quite successful. > >>> What tftpd? Have you reviewed the logs for partial transfers? >> atftpd >> here's the syslog output. > ..snip > >> The .c32 files transfered are EFI64 files. I just copied them into the root >> directory for testing purposes. As soon as the images load I will organize >> the structure properly > I could have asked what version but since you've finally described the > symptoms sufficiently, I'm already aware it won't matter. >Strange thing is that it worked with Elilo. Since elilo is deprecated we now try to switch to syslinux for BIOS and EFI. I am currently trying everythin on VMs. Since Hpyer-V is currently out out reach and Virtualbox does not boot from EFI Network devices i can only test on VMware VMs. -- Mathias Radtke, uib mail m.radtke at uib.de
>>>> What do you observe?? Does it transfer the file then the Linux kernel > crashes?? Does it spontaneously reboot before completing the > operation? The client is a VSphere VM Client. It displayes the IP Address and then: Loading Kernel..... ok Loading initrd.bz2... This stalls for minutes and the client reboots afterwards. <<< I have seen this before; Are you using VMware 12 ? try changing the virtual driver. I have reported a bug on certain VMware drivers that mistakenly set TFTP blocksize to 1486 instead of 1468, That leads to IP fragmentation and high chances of an aborted TFTP transfer if the file is big. See here: https://communities.vmware.com/message/2536960 A Wireshark traffic capture will confirm if you are suffering this VMware bug VMware is lately having some issues with TFTP transfers, This is another reported bug that produces extremely low speed TFTP transfers under EFI; this could also lead to aborted transfers if the file is big. https://communities.vmware.com/message/2536774 Best, Patrick
On 21.09.2015 13:32, Patrick Masotta wrote:> > What do you observe? Does it transfer the file then the Linux kernel > > crashes? Does it spontaneously reboot before completing the > > operation? > The client is a VSphere VM Client. It displayes the IP Address and > then: > Loading Kernel..... ok > Loading initrd.bz2... > > This stalls for minutes and the client reboots afterwards. > <<< > > I have seen this before; Are you using VMware 12 ? > try changing the virtual driver. > I have reported a bug on certain VMware drivers that > mistakenly set TFTP blocksize to 1486 instead of 1468, > That leads to IP fragmentation and high chances of an aborted > TFTP transfer if the file is big. See here: > https://communities.vmware.com/message/2536960 > A Wireshark traffic capture will confirm if you are suffering > this VMware bug > > VMware is lately having some issues with TFTP transfers, > This is another reported bug that produces extremely > low speed TFTP transfers under EFI; this could also lead > to aborted transfers if the file is big. > https://communities.vmware.com/message/2536774 > > Best, > Patrick >Server is VMWare ESXi 5.5 Cheers -- Mathias Radtke, uib mail m.radtke at uib.de