Hide Forgot
Description of problem: Booting using a Red Hat Enterprise Linux (RHEL) 6.0 pxe server's chain.c32 from an already installed machine does not result in the machine booting from the local installed OS. The boot fail instead. Version-Release number of selected component (if applicable): syslinux-3.86-1.1.el6.x86_64 How reproducible: always Steps to Reproduce: 1. set up a working tftpd service and configure your dhcp server accordingly 2. copy: /usr/share/syslinux/pxelinux.0 /usr/share/syslinux/chain.c32 in your tftpboot/ folder 3. enter a configuration file under tftpboot/pxelinux.cfg/ containing: TIMEOUT 10 IPAPPEND 2 DEFAULT local_primary PROMPT 1 LABEL local_primary KERNEL chain.c32 APPEND hd0 Try to pxeboot a remote machine with a working installation on its local disk. Actual results: Boot fails. Expected results: Remote machine should boot from its local disk. Additional info: There is a workaround for this bug which consists in using the instruction LOCALBOOT 0 instead of KERNEL chain.c32 APPEND hd0 in the conf file under pxelinux.cfg/ Newer versions of syslinux are affected as well (up to upstream 4.04-pre7). Previous version 3.11 (RHEL-5) works as expected.
Hello, I'm still trying to find out the exact cause for this: the bug has been introduced in the upstream syslinux-3.74 version (the syslinux 3.73 works as expected). The chain.c32 module itself has not changed between these two versions, so the problem lies most probably in the pxelinux changes. I suspect the code for IPAPPEND option has broken the module parameters passing and chain.c32 doesn't see the "hd0" option at all. My assembly-fu is very weak so I failed to find the exact place or to confirm my theory. I'll keep tinkering... Regards.
There is no evidence what machine this is anywhere in the body, but I'm going to make a wild guess that it's an HP server. Quite a few HP servers have BIOSes that use memory unsafely for localbooting; older PXELINUX versions didn't happen to use the critical memory locations out of pure dumb luck. Unfortunately there is very little that can be done to avoid them, other than possibly breaking pxelinux.0 into two files loaded at different addresses, which is likely to break *other* machines.
Hello, I did my tests with KVM virtual machines -- so there either must be a similar bug also in the BIOS binary we ship with the qemu-kvm or the problem is more generic. Regards.
Oh. I just looked at the code; yes, the global "ipappend" is almost certainly the culprit here. Global "append" or "ipappend" cause a lot of problems; just don't use them.
Setting devel_ack- per comments 5-7. As explained in the opening comment, a reasonable workaround is available. As noted in comment #7, a global APPEND or IPAPPEND should not be used as it leads to other problems. GSS is documenting the workaround as a knowledge base article.
There is a valid usecase where the workaround does not help: LABEL other MENU LABEL run bootsector on other partition KERNEL chain.c32 APPEND hd0 2 If customers have multiple partitions with installed independent operating systems then with chainload they could via pxe/tftp and chain.c32 conveniently select which partitions system to start, while the workaround does not provide this. Considering to open this as we have no workaround, but maybe GPXE helps here.
W.r.t. comment #9 - that should work just fine (without a global APPEND or IPAPPEND). What does your entire configuration look like?
Thank you much for pointing out! This works indeed, we were just wrangling with the global (I)APPEND here. Adjusting documentation to point this out.
Changing bz subject to reflect the actual issue: - chainloading with chain.c32 works - using APPEND/IPAPPEND in the global area does not, this is what the 'CLOSED CANTFIX' relates to