similar to: EFI: HP + syslinux = crash

Displaying 20 results from an estimated 800 matches similar to: "EFI: HP + syslinux = crash"

2015 Jul 31
2
EFI: HP + syslinux = crash
>[...] > NBP file downloaded successfully. > Getting cached packet > My IP is 10.141.166.254 > core_tcp_connect: stalling on configure with no mapping > core_tcp_connect: stalling on configure with no mapping > core_tcp_connect: stalling on configure with no mapping > core_tcp_connect: stalling on configure with no mapping
2015 Jul 31
0
EFI: HP + syslinux = crash
>>> For the record: During the first tests, the System ROM is at version 1.32 and the NIC Firmware is at version 2.13.5. The result for version 6.0.3 compiled from the tarball: ? ???>> Booting Embedded LOM 1 Port 1 : HP Ethernet 1Gb 4-port 331i Adapter ? ???- NIC (PXE IPv4) ? ???>> Booting PXE over IPv4. ? ???Station IP address is 10.141.166.254 ? ???Server
2017 May 31
6
[PATCH 1/4] efi/udp: core_udp_connect should use SubnetMask not StationAddress for netmask
Signed-off-by: Julien Viard de Galbert <jviarddegalbert at online.net> --- efi/udp.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/efi/udp.c b/efi/udp.c index 1088f47..b0f13ad 100644 --- a/efi/udp.c +++ b/efi/udp.c @@ -163,7 +163,7 @@ void core_udp_connect(struct pxe_pvt_inode *socket, uint32_t ip, } else { udata.UseDefaultAddress = FALSE;
2015 Apr 08
3
syslinux.efi with QEMU/OVMF
On Tue, 7 Apr 2015, Laszlo Ersek wrote: > Whereas syslinux.efi apparently uses the embedded gpxe/ tree, and that > one uses TCP timestamps. See tcp_xmit() in gpxe/src/net/tcp.c: Actually syslinux.efi seems to be using the implementation calling into UEFI via these functions: http://git.kernel.org/cgit/boot/syslinux/syslinux.git/tree/efi/tcp.c I've tried to add debug messages to these
2015 Apr 07
3
syslinux.efi with QEMU/OVMF
Hello, I'm trying to find out how to pxe boot with syslinux.efi on QEMU with OVMF. After getting through the initial hurdle caused by the iPXE based option ROM included with QEMU having a problem as described in these threads: http://www.syslinux.org/archives/2014-November/022804.html http://sourceforge.net/p/edk2/mailman/message/33236100/ I'm now getting further to almost being able
2015 Jun 11
2
EFI/PXE boot on Oracle X5-2
Hello all, I am seeing the same symptoms described here by Holger Baust on 5-Feb-2015. The only differences in our setups that I can see are that Mr. Baust claimed to be using HP DL380p Gen9, whereas I'm on an Oracle X5-2, and Mr. Baust claimed to be using vlan tagging, while I am not. Boot log: Copyright (C) 2014, Oracle and/or its affiliates. All rights reserved. Version 2.16.1243.
2013 Nov 10
2
syslinux.efi pxeboot across multiple subnets
On Sat, Nov 9, 2013 at 9:22 AM, Jason Matthews <jason.david.matthews at gmail.com> wrote: > The setup I was using was in a chassis. Slot 8 of the chassis is the client > machine. It goes through Switch 1 (a Brocade switch) to the top of rack > (BNT). The mirror is in the chassis switch. Slot 3 of the same chassis is > connected to the mirror port in Switch 1. > > client =
2015 Feb 05
0
Problems with EFI PXE boot on Hp DL380p Gen9
On Thu, Feb 05, 2015 at 07:02:07PM +0100, Holger Baust wrote: > Hello. > > We are using pxelinux for years to boot Linux via PXE since years. > Since EFI is spreading, I changed configuration to be able to boot EFI > systems. > > The "Client": > - HP Proliant DL380Gen9 System FW: 1.21 11/03/2014, latest available > - NIC used for booting: HP Embedded LOM 331i
2015 Feb 05
2
Problems with EFI PXE boot on Hp DL380p Gen9
Hello... Am 05.02.15 um 23:33 schrieb Geert Stappers via Syslinux: > On Thu, Feb 05, 2015 at 07:02:07PM +0100, Holger Baust wrote: >> Hello. >> >> We are using pxelinux for years to boot Linux via PXE since years. >> Since EFI is spreading, I changed configuration to be able to boot EFI >> systems. >> >> The "Client": >> - HP Proliant
2015 Jun 22
1
EFI: PXE: "My IP is 0.0.0.0"
On Mon, Jun 22, 2015 at 6:03 AM, S. Schauenburg <s.schauenburg at gmail.com> wrote: > Ady2 suggested to me on IRC to add additional information to the ML. > > With BIOS P89 v1.32 (03/05/2015) I saw errors from core_udp_sendto: > Getting cached packet > My IP is 0.0.0.0 > core_udp_sendto: stalling on configure with no mapping > core_udp_sendto: stalling on configure with
2015 Feb 05
4
Problems with EFI PXE boot on Hp DL380p Gen9
Hello. We are using pxelinux for years to boot Linux via PXE since years. Since EFI is spreading, I changed configuration to be able to boot EFI systems. The "Client": - HP Proliant DL380Gen9 System FW: 1.21 11/03/2014, latest available - NIC used for booting: HP Embedded LOM 331i (Broadcom BCM 5719/ tg3), FW: 5719-v1.38 The Server: - ISC-DHCP with tfpd-hpa running on Debian 6.x -
2015 Feb 06
0
Problems with EFI PXE boot on Hp DL380p Gen9
On Fri, Feb 06, 2015 at 12:08:58AM +0100, Holger Baust via Syslinux wrote: > Hello... Welcome the Syslinux project! > Am 05.02.15 um 23:33 schrieb Geert Stappers via Syslinux: > > On Thu, Feb 05, 2015 at 07:02:07PM +0100, Holger Baust wrote: <snip/> > >> > >> NBP file downloaded successfully. > >> Getting chached packet > >> My IP is
2015 Feb 06
2
Problems with EFI PXE boot on Hp DL380p Gen9
Am 06.02.2015 um 07:44 schrieb Geert Stappers via Syslinux: > On Fri, Feb 06, 2015 at 12:08:58AM +0100, Holger Baust via Syslinux wrote: >> Hello... > Welcome the Syslinux project! > > >> Am 05.02.15 um 23:33 schrieb Geert Stappers via Syslinux: >>> On Thu, Feb 05, 2015 at 07:02:07PM +0100, Holger Baust wrote: > <snip/> >>>> NBP file
2015 Jul 31
0
EFI: HP + syslinux = crash
>>> > >???So...this is EFI_NO_MAPPING. Is this very different from the >???EFI_NO_MEDIA I get when booting via iPXE? > <<< > > very unlikely.... <<< I really meant unlikely to be related issues... >>> > A complete wireshark traffic capture would be handy. I will send you one directly. I can reveal now that it will not contain
2015 Aug 31
4
HP EFI binaries
On Mon, Aug 31, 2015 at 06:08:19AM -0400, Gene Cumm via Syslinux wrote: > On Aug 30, 2015 8:42 PM, "Derrick" <derrick22 at gmail.com> wrote: > > > > Gene thanks, here is the output > > > > My IP is 10.2.49.10 > > Img @ 71d89718 = 8cdcd40ca5f0 > > Udp @ 71d89718 = 8cdcd40ca5f0 > > Udp @ 71d89718 = 8cdcd40ca5f0 > > Udp @ 71d89718 =
2013 Nov 11
2
syslinux.efi pxeboot across multiple subnets
On Mon, Nov 11, 2013 at 4:53 PM, Jason Matthews <jason.david.matthews at gmail.com> wrote: > On Sun, Nov 10, 2013 at 12:23 PM, Gene Cumm <gene.cumm at gmail.com> wrote: > >> On Sat, Nov 9, 2013 at 9:22 AM, Jason Matthews >> <jason.david.matthews at gmail.com> wrote: >> > The setup I was using was in a chassis. Slot 8 of the chassis is the >>
2015 Jun 12
0
EFI/PXE boot on Oracle X5-2
On Thu, Jun 11, 2015 at 12:46 PM, Michael Glasgow via Syslinux <syslinux at zytor.com> wrote: > Hello all, > > I am seeing the same symptoms described here by Holger Baust on > 5-Feb-2015. The only differences in our setups that I can see are > that Mr. Baust claimed to be using HP DL380p Gen9, whereas I'm on > an Oracle X5-2, and Mr. Baust claimed to be using vlan
2015 Oct 09
1
syslinux64.efi boot problems
Hi there, I've been trying to boot some new machines via uEFI and it does not work, as you can see below. From my hunting around on the mailing list, there may have been a bunch of fixes that have been committed that have some bearing on uEFI, and even some on the mailing list that appear to be aimed at solving similar problems. However, I can't manage to build a new one based on the
2015 Jun 15
1
EFI/PXE boot on Oracle X5-2
On Thu, Jun 11, 2015 at 10:30 PM, Gene Cumm <gene.cumm at gmail.com> wrote: > On Thu, Jun 11, 2015 at 12:46 PM, Michael Glasgow via Syslinux > <syslinux at zytor.com> wrote: >> Hello all, >> >> I am seeing the same symptoms described here by Holger Baust on >> 5-Feb-2015. The only differences in our setups that I can see are >> that Mr. Baust
2015 Jul 31
5
EFI: ipxe + syslinux = Failed to read blocks: 0xC
Hello dear list, Using VMware I built a test setup of a server with dhcp, tftp and a http-server and several pxe-clients with EFI mode turned on. This setup worked, albeit with the exponential-like decay of IO rate I described earlier. The work-around of using HTTP works beautifully though. So it was time for the next step. Migrate this setup to our automated testing environment that runs