[syslinux] lpxelinux.0 issues with larger initrd.img files from RHEL >= 7.5 on UCS servers?
Ady Ady
ady-sf at hotmail.com
Wed Jun 19 16:15:36 PDT 2019
> > 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.
More information about the Syslinux
mailing list