Syslinux - Sep 2015 - Problem with 90MB Initrd

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.
> 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 want COM32s in more than one, I suggest
> different directories or one of the other approaches in the WIKI.
Removing quiet seems not to give me more output. The loader just asks 
for ldlinux.e$ARCH$

-- 
Mathias Radtke, uib

mail m.radtke at uib.de

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?

Have you considered HTTP transfer?

What do you observe?  Does it transfer the file then the Linux kernel
crashes?  Does it spontaneously reboot before completing the
operation?

Have you tried doing a packet capture to see how far this client progresses?

What tftpd?  Have you reviewed the logs for partial transfers?

-- 
-Gene

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