On 10/26/2015 7:47 PM, Gene Cumm wrote:> On Mon, Oct 26, 2015 at 2:09 PM, Alan Sparks via Syslinux > <syslinux at zytor.com> wrote:>> For reference this is on different models of HP Proliant Gen-9 systems >> with UEFI. Firmware as up to date as it comes. The UEFI boot order >> has the hard drives and OS ESPs before the PXE interfaces (the default). >> A boot-from-cold loads the OS no problem. > > So PXE is the last option? Are you manually selecting PXE from this > NIC or is the server automatically selecting this?More details: * The local disks were first in the boot order. NICs (more than one) were at the bottom of the boot order. * This is a "one time boot" from PXE. Same whether I choose network boot from the console (F12 on a ProLiant) or via a remote IPMI "bootdev pxe" sort of control. * I've tried reordering the boot order. See below.> >> Here's what I've tried so far: > > Did you try inserting another boot selection after PXE, even if it's a > repeat like CD? My current theory is it's either a bug in Syslinux > calling back incorrectly or it's the firmware not using the data right > and looping. >With Gene's recent test binaries, localboot (0 or 1) for argument: * I've tried reordering the boot order, putting disks after the NICs. Basically putting the PXE interface that can boot at the top, other stuff (disks, USB, etc) last. * The boot menu is displayed. When the localboot option is triggered, it /appears/ that the system may be trying to move to the next PXE option - for this system, the PXE nic also has a IPv6 option that I left at the end of the boot order - so what appears to have happened is after the localboot executing, the system skipped over the disk items, and found the next PXE option in the list. It did not try to boot the disk.
On Tue, Oct 27, 2015 at 1:44 PM, Alan Sparks <asparks at doublesparks.net> wrote:> On 10/26/2015 7:47 PM, Gene Cumm wrote: >> On Mon, Oct 26, 2015 at 2:09 PM, Alan Sparks via Syslinux >> <syslinux at zytor.com> wrote: > >>> For reference this is on different models of HP Proliant Gen-9 systems >>> with UEFI. Firmware as up to date as it comes. The UEFI boot order >>> has the hard drives and OS ESPs before the PXE interfaces (the default). >>> A boot-from-cold loads the OS no problem. >> >> So PXE is the last option? Are you manually selecting PXE from this >> NIC or is the server automatically selecting this? > > More details: > * The local disks were first in the boot order. NICs (more than one) > were at the bottom of the boot order. > * This is a "one time boot" from PXE. Same whether I choose network > boot from the console (F12 on a ProLiant) or via a remote IPMI "bootdev > pxe" sort of control. > * I've tried reordering the boot order. See below. > >> >>> Here's what I've tried so far: >> >> Did you try inserting another boot selection after PXE, even if it's a >> repeat like CD? My current theory is it's either a bug in Syslinux >> calling back incorrectly or it's the firmware not using the data right >> and looping. >> > > With Gene's recent test binaries, localboot (0 or 1) for argument: > * I've tried reordering the boot order, putting disks after the NICs. > Basically putting the PXE interface that can boot at the top, other > stuff (disks, USB, etc) last. > * The boot menu is displayed. When the localboot option is triggered, > it /appears/ that the system may be trying to move to the next PXE > option - for this system, the PXE nic also has a IPv6 option that I left > at the end of the boot order - so what appears to have happened is after > the localboot executing, the system skipped over the disk items, and > found the next PXE option in the list. It did not try to boot the disk.My point was this: Reorder the boot order to the working NIC, then other devices. After that, let it auto-boot and see what LOCALBOOT does. -- -Gene
On 10/27/2015 7:52 PM, Gene Cumm wrote:> On Tue, Oct 27, 2015 at 1:44 PM, Alan Sparks <asparks at doublesparks.net> wrote: >> * The boot menu is displayed. When the localboot option is triggered, >> it /appears/ that the system may be trying to move to the next PXE >> option - for this system, the PXE nic also has a IPv6 option that I left >> at the end of the boot order - so what appears to have happened is after >> the localboot executing, the system skipped over the disk items, and >> found the next PXE option in the list. It did not try to boot the disk. > > My point was this: Reorder the boot order to the working NIC, then > other devices. After that, let it auto-boot and see what LOCALBOOT > does. >Tried that as well. It still repeated the menu, did not proceed to the disk.
> > With Gene's recent test binaries, localboot (0 or 1) for argument: > * I've tried reordering the boot order, putting disks after the NICs. > Basically putting the PXE interface that can boot at the top, other > stuff (disks, USB, etc) last.Could you please clarify? You previously wrote that you used 'localboot -1' (that's a minus one), and now you write 'localboot 1'. I would suggest setting in the firmware the relevant NIC as first boot device, and then the relevant HDD as second boot device. If the boot order in the firmware can only select a generic "HDD" item (as opposed to selecting a specific HDD connected to a specific device port), I would suggest looking also at additional settings in the firmware. For troubleshooting purposes, I would suggest connecting the relevant HDD to the "first" port available, disabling / disconnecting any other storage devices. I would suggest a similar procedure with potential NICs (or with any other alternative network boot method) leaving only the main network boot method that is being used (as the first boot device, for these tests). I understand that this could be time-consuming, and not always possible. Unfortunately, there are only few ways that we can actually help without having direct access to the same exact setup, so restricting / limiting the setup to the most minimal and simplified possible could perhaps be the only way to trigger a different behavior that could give us some clue as to where the source of the problem could be located. I would also suggest potential alternative commands: _ localboot 0 _ localboot -1 _ localboot 0x80 _ localboot 128 Not all of them will work (for several reasons), but that's beyond the point. The goal would be to trigger (one way or another) different behaviors or different error messages, so the different potential results could help narrow down the source of the problem. Let's also not forget that the behavior of the 'localboot' directive has been always dependent on the firmware capabilities. Regards, Ady