search for: 90mb

...the requesting client. However when I try to boot our companies miniroot the DHCP serves the file, but it seems like it never finishes. The image is generated with the following command: find . | grep -v 'name'.bz2 | cpio -o -H newc | bzip2 > 'name'.bz2 The image has a size of 90MB. The kernel loads fine, and when I try to boot it without an initrd it panics (obious). I tried to use another kernel and also an ubuntu install CD initrd and it then booted fine. Is there anything else I can do to make our miniroot booting? Here's the pxelinux.cfg/default config: default...

...> However when I try to boot our companies miniroot the DHCP serves the file, > but it seems like it never finishes. > The image is generated with the following command: > find . | grep -v 'name'.bz2 | cpio -o -H newc | bzip2 > 'name'.bz2 > The image has a size of 90MB. 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 kernel loads fine, and when I try to boot it without an initrd it panics > (obious). &...

...cal 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? Have you considered HTTP transfer? Wha...

...lt;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/ini...

...his 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. > 2) Start by removing quiet. it may be supressing your status. > > DHCPd config is fine as long as you never want any COM32s in more than > one architecture. If you wan...

>>> > 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

>>> > > 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: >

>>> Patrick, the pattern is quite recognizable.? See also "[syslinux] EFI & PXE-booting: very slow TFTP performance on a VMWare test setup" http://www.syslinux.org/archives/2015-June/023634.html -Gene <<< Gene, As I see it there are two completely different TFTP problems here: The one initially reported by Oscar Roozen lead to this bug report

>>> > BTW if you take a minute and read the first report > https://communities.vmware.com/message/2536774 > You'll realize that VMWare TFTP "surprisingly" does not present slow TFTP transfers > when they are driven by MS "bootmgfw.efi"; instead the problem is only shown when > transfers are driven by syslinux.efi; At the moment, despite

>>> On 09/26/2015 10:36 AM, Patrick Masotta via Syslinux wrote: > > About PXEbc Peter has recently said: >> The problem with the pxebc is that it only supports one concurrent TFTP >> connection, and Syslinux expects to be able to keep multiple files open >> at the same time. >> http://www.syslinux.org/archives/2015-August/024025.html > > I wonder why

On Wed, Sep 23, 2015 at 4:58 PM, Gene Cumm <gene.cumm at gmail.com> wrote: > On Wed, Sep 23, 2015 at 4:24 PM, Patrick Masotta <masottaus at yahoo.com> wrote: >>>>> >> >> > BTW if you take a minute and read the first report >> > https://communities.vmware.com/message/2536774 >> > You'll realize that VMWare TFTP

>>> >I do not understand.Are we parsing a configuration file and potentially>starting new TFTP transfers while downloading it? How can we do this on >a single thread?We cannot stop/resume a TFTP transfer then I cannot >imagine how to detect an INCLUDE during TFTP transfer N to launch TFTP >transfer N+1 if TFTP transfer N is not finished yet, all in a single >thread and

> On September 29, 2015 7:45:27 PM PDT, Patrick Masotta <masottaus at yahoo.com> wrote: >>>>> >>On 09/26/2015 10:36 AM, Patrick Masotta via Syslinux wrote: >>> >>> About PXEbc Peter has recently said: >>>> The problem with the pxebc is that it only supports one concurrent >>TFTP >>>> connection, and Syslinux expects to

On 10/1/2015 6:18 AM, Patrick Masotta via Syslinux wrote: > -Gene<<< > Considering any editing/buffering benefits are only marginal (AFAIK) there are not benefits with the current approach.On the other hand the list of potential problems includes: > 1) We cannot use the ubiquitous EFI PXEbc protocol forcing us to rely on the (not always present) EFI Binding Services. >

>>> > Considering any editing/buffering benefits are only marginal (AFAIK) there are not benefits with the current approach.On the other hand the list of potential problems includes: > 1) We cannot use the ubiquitous EFI PXEbc protocol forcing us to rely on the (not always present) EFI Binding Services. > Best,Patrick Speaking utterly ignorantly here... could this switch help

On 10/01/2015 05:18 AM, Patrick Masotta via Syslinux wrote: > > Aside from potentially needing smaller buffers for config files before > parsing (which seems trivial and unnecessary), what other benefits are > there to this strategy? > At the core, is that Syslinux is a general bootloader which gives access to a virtual filesystem. It supports multiple open files, but not

>>> > On 10/1/2015 6:18 AM, Patrick Masotta via Syslinux wrote: > > > -Gene<<< > > Considering any editing/buffering benefits are only marginal (AFAIK) there are not benefits with the current approach.On the other hand the list of potential problems includes: > > 1) We cannot use the ubiquitous EFI PXEbc protocol forcing us to rely on the (not always

Background images come to mind. On October 2, 2015 5:23:18 AM PDT, Patrick Masotta <masottaus at yahoo.com> wrote: >>>> >> >> Aside from potentially needing smaller buffers for config files >before >> parsing (which seems trivial and unnecessary), what other benefits >are >> there to this strategy? >> > >At the core, is that Syslinux

>>> >Do you remember other reasons besides "INCLUDE" handling that today >might depend on multiple in-progress TFTP transfers?Thanks, >Best, >Patrick Background images come to mind. -hpa <<< Got it; but background images are always uninterrupted transfers right? I'll try to see how difficult this change might be; if you remember some other point to

> <<< Please correct me if I'm wrong: Supporting multiple open files > could've been done mapping the "whole" file in memory w/o requiring > multiple in-progress TFTP transfers right? >>> The following comments will be dismissed (or ignored) by some readers (or even by many of them), with qualifiers such as "irrelevant" (or possibly