Syslinux - Jun 2019 - lpxelinux.0 issues with larger initrd.img files from RHEL >= 7.5 on UCS servers?

> > Sounds like you may want to contact Cisco...
> 
> And tell them what? There's a bug in their PXE/BIOS stack somewhere?
 
 
Just some random and humble thoughts...

Perhaps it would be worth some additional tests?

Maybe a test with pxelinux.0 version 4.07? And using "LINUX", not 
"KERNEL":

###
DEFAULT biginitrd
PROMPT 0
LABEL biginitrd
LINUX mykernel
INITRD mybiginitrd
APPEND myoptions
###

Maybe a packet capture might reveal something about the network setup?

Maybe it is not the size of the initrd file but rather a time 
limitation (which gets triggered by a big-enough file)?

What about trying with 6.04-pre1, and/or (even better) with Debian 
Sid's packages and using debug.c32 (from the corresponding 
package/version/build):

###
DEFAULT dbg
PROMPT 1
SAY First press [Enter] for debug.c32, then [1][Enter] for OS.

# Once in the boot prompt, press "Enter".
LABEL dbg
COM32 debug.c32
APPEND -e pxe_call,malloc
# Additional functions for debug might be of interest.


# After debug.c32 returns to the boot prompt,
# press "1" and "Enter".
LABEL 1
LINUX mykernel
INITRD mybiginitrd
APPEND myoptions
###


Once the label named "1" is launched, is there any info (that could 
help)?

Please avoid using boot menus for these tests; use the boot prompt.

Sometimes a "cold" boot behaves differently than a "warm"
boot. This
might be (particularly) relevant when performing multiple cycles of 
(network) booting (tests).

Another possible test could be to use UEFI mode instead of CSM; in such 
case the bootloader would be (efi64's) syslinux.efi + ldlinux.e64 ( + 
efi64's debug.c32). As usual, all files from the same set of 
package/version/build.

Considering the lack of specific, knowledgeable replies about this 
topic in this Syslinux mailing list so far, maybe a test with a 
different bootloader (at least for comparison of resulting behavior) 
would be worth?

Recurrent failures in all tests would probably indicate either:
 _ a bug in the firmware; or,
 _ some problem with the specific kernel+initrd combo (in this 
hardware); or,
 _ some problem with the network setup.

OTOH, if a successful boot can be achieved by at least one test, then 
either a bug or a limitation in (l)pxelinux.0 might be exposed by this 
hardware/firmware.

As I mentioned, these are some random and humble thoughts; they might 
not be 
worth much (or even nothing at all).

Regards,
Ady.

Hello,

On Wed, Jun 19, 2019 at 11:15:36PM +0000, Ady Ady via Syslinux
wrote:
> Just some random and humble thoughts...
> 
> Perhaps it would be worth some additional tests?
> 
> Maybe a test with pxelinux.0 version 4.07? And using "LINUX", not
> "KERNEL":
> 
> ###
> DEFAULT biginitrd
> PROMPT 0
> LABEL biginitrd
> LINUX mykernel
> INITRD mybiginitrd
> APPEND myoptions
> ###
I will try that.
> Maybe a packet capture might reveal something about the network setup?
> 
> Maybe it is not the size of the initrd file but rather a time 
> limitation (which gets triggered by a big-enough file)?
If it's a timing difference it's going to be tricky: I converted to http
instead of tftp because the transmission time is a least an order of
magnitude faster over http...
> What about trying with 6.04-pre1, and/or (even better) with Debian 
> Sid's packages and using debug.c32 (from the corresponding 
> package/version/build):
Tried that already (the version from debian that is), it failed the same way.
> ###
> DEFAULT dbg
> PROMPT 1
> SAY First press [Enter] for debug.c32, then [1][Enter] for OS.
> 
> # Once in the boot prompt, press "Enter".
> LABEL dbg
> COM32 debug.c32
> APPEND -e pxe_call,malloc
> # Additional functions for debug might be of interest.
> 
> 
> # After debug.c32 returns to the boot prompt,
> # press "1" and "Enter".
> LABEL 1
> LINUX mykernel
> INITRD mybiginitrd
> APPEND myoptions
> ###
> 
> 
> Once the label named "1" is launched, is there any info (that
could
> help)?
> 
> Please avoid using boot menus for these tests; use the boot prompt.
I'll give that a shot as well.
> Sometimes a "cold" boot behaves differently than a
"warm" boot. This
> might be (particularly) relevant when performing multiple cycles of 
> (network) booting (tests).
Tried that as well, doesn't make any difference.
> Another possible test could be to use UEFI mode instead of CSM; in such 
> case the bootloader would be (efi64's) syslinux.efi + ldlinux.e64 ( + 
> efi64's debug.c32). As usual, all files from the same set of 
> package/version/build.
I am not in charge of the configuration of the servers so while I could
test to boot over the network while using UEFI, even if it works, I'll
still be installing servers using CSM...
> Considering the lack of specific, knowledgeable replies about this 
> topic in this Syslinux mailing list so far, maybe a test with a 
> different bootloader (at least for comparison of resulting behavior) 
> would be worth?
> 
> Recurrent failures in all tests would probably indicate either:
>  _ a bug in the firmware; or,
>  _ some problem with the specific kernel+initrd combo (in this 
> hardware); or,
>  _ some problem with the network setup.
> 
> OTOH, if a successful boot can be achieved by at least one test, then 
> either a bug or a limitation in (l)pxelinux.0 might be exposed by this 
> hardware/firmware.
Well in my initial post, I pointed out these kinds of servers had no
problem booting older/smaller initrd files. As soon as the files grew,
they failed.
> As I mentioned, these are some random and humble thoughts; they might 
> not be 
> worth much (or even nothing at all).
Thanks for your input!

-- 
Mathieu Chouquet-Stringer                               m+syslinux at thi.eu.com
            The sun itself sees not till heaven clears.
	             -- William Shakespeare --

Hi,

I tried more syslinux/pxelinux versions and I can report the following
while using pxelinux.0:
4.03 OK (server boots fine)
4.07 OK (server boots fine)
5.00 KO (server reboots)
5.01 KO (server reboots)
5.10 KO (server reboots)
6.0* KO (server reboots)

Next step is to try the debug.c32 stuff I guess...

On Thu, Jun 20, 2019 at 08:52:44PM +0200, Mathieu Chouquet-Stringer
wrote:
> > Maybe a packet capture might reveal something about the network setup?
> > 
> > Maybe it is not the size of the initrd file but rather a time 
> > limitation (which gets triggered by a big-enough file)?
> 
> If it's a timing difference it's going to be tricky: I converted to
http
> instead of tftp because the transmission time is a least an order of
> magnitude faster over http...
> 
> > ###
> > DEFAULT dbg
> > PROMPT 1
> > SAY First press [Enter] for debug.c32, then [1][Enter] for OS.
> > 
> > # Once in the boot prompt, press "Enter".
> > LABEL dbg
> > COM32 debug.c32
> > APPEND -e pxe_call,malloc
> > # Additional functions for debug might be of interest.
> > 
> > 
> > # After debug.c32 returns to the boot prompt,
> > # press "1" and "Enter".
> > LABEL 1
> > LINUX mykernel
> > INITRD mybiginitrd
> > APPEND myoptions
> > ###
> > 
> > 
> > Once the label named "1" is launched, is there any info
(that could
> > help)?
> > 
> > Please avoid using boot menus for these tests; use the boot prompt.
> 
> I'll give that a shot as well.
> 
-- 
Mathieu Chouquet-Stringer                               m+syslinux at thi.eu.com
            The sun itself sees not till heaven clears.
	             -- William Shakespeare --