similar to: Xen4CentOS: Unnecessary gpxe / ipxe obsoletes

On Sat, Oct 24, 2015 at 6:15 PM, Michael Brown via Syslinux <syslinux at zytor.com> wrote: > Also, not a fork: http://git.ipxe.org/ipxe.git/commitdiff/8406115 A fork is a fork, regardless the reasons behind it (yes, I have some understanding in this case). iPXE is based off of forking further development as of a certain gPXE commit with some backporting of gPXE development to iPXE. --

The gPXE in the Syslinux tree is ridiculously old. We could either replace it with iPXE or just drop it, giving people a recipe for how to integrate with iPXE themselves. What do people think? -hpa

Hi All, I've been trying to understand how to use pxechn.c32 to chain a local pxelinux menu item to a remote server which has it's own pxelinux hierarchy served via TFTP and HTTP. We have no control over DHCP next-server and filename fields so I wanted to exploit the "prefix" -p option that pxechn.c32 accepts. I spent a long time hitting my head against a brick wall until I

On Thu, Oct 10, 2013 at 10:00 AM, Michael Brown <mbrown at fensystems.co.uk> wrote: > On 09/10/13 10:45, Robin Smidsr?d wrote: >> >> On 09.10.2013 02:56, H. Peter Anvin wrote: >>> >>> The gPXE in the Syslinux tree is ridiculously old. We could either >>> replace it with iPXE or just drop it, giving people a recipe for how to >>> integrate

For me the motivation for gpxelinux.0 was the HTTP support. If this would work reliably in newer versions then I could happily live without a iPXE-based pxelinux. On 9 October 2013 13:36, Ferenc Wagner <wferi at niif.hu> wrote: > "H. Peter Anvin" <hpa at zytor.com> writes: > > > The gPXE in the Syslinux tree is ridiculously old. We could either > >

Possibly authority variable (initialized with NULL) might be dereferenced when an arbitrary path (without "//" on it) is supplied to parse_uri() function Signed-off-by: Felipe Pena <felipensp at gmail.com> --- gpxe/src/core/uri.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/gpxe/src/core/uri.c b/gpxe/src/core/uri.c index 6a1f2e5..4987821 100644 ---

Signed-off-by: Gilles Espinasse <g.esp at free.fr> --- gpxe/src/Makefile.housekeeping | 10 ++++++++++ 1 files changed, 10 insertions(+), 0 deletions(-) diff --git a/gpxe/src/Makefile.housekeeping b/gpxe/src/Makefile.housekeeping index 1f5e115..d49416e 100644 --- a/gpxe/src/Makefile.housekeeping +++ b/gpxe/src/Makefile.housekeeping @@ -134,6 +134,16 @@ SP_FLAGS := $(shell $(SP_TEST)

On Tue, Jul 16, 2013 at 6:26 AM, Gene Cumm <gene.cumm at gmail.com> wrote: > On Mon, Jul 15, 2013 at 11:57 PM, Alexandre Blanchette > <blanalex at gmail.com> wrote: > > In PXELinux 4.06 (the vanilla version, not gpxelinux.0), I'm trying to > use > > pxechn.c32 to call iPXE (undionly) with option 67 set to call an iPXE > > script. > > > > The

On Thu, Sep 24, 2015 at 6:33 AM, Gene Cumm <gene.cumm at gmail.com> wrote: > Now I have something I can reproduce. Booting my same ipxe.iso to > perform an initial TFTP load shows what I saw already. Attempting to > load a file via http results in an immediate error message with no > resulting traffic as far as I can see. OK. Found it. core/fs/pxe/pxe.h disabled all of the

On 25/10/15 01:04, Gene Cumm wrote: > On Sat, Oct 24, 2015 at 6:15 PM, Michael Brown via Syslinux > <syslinux at zytor.com> wrote: > >> Also, not a fork: http://git.ipxe.org/ipxe.git/commitdiff/8406115 > > A fork is a fork, regardless the reasons behind it (yes, I have some > understanding in this case). iPXE is based off of forking further > development as of a

On Thu, Sep 24, 2015 at 07:57:47AM -0600, Alan Sparks via Syslinux wrote: > On 9/24/2015 4:59 AM, Gene Cumm wrote: > > On Thu, Sep 24, 2015 at 6:33 AM, Gene Cumm <gene.cumm at gmail.com> wrote: > > > >> Now I have something I can reproduce. Booting my same ipxe.iso to > >> perform an initial TFTP load shows what I saw already. Attempting to > >>

> The gPXE in the Syslinux tree is ridiculously old. We could either > replace it with iPXE or just drop it, giving people a recipe for how to > integrate with iPXE themselves. > > What do people think? My vote is replace with iPXE. I've manually replaced gPXE with iPXE for years, works like charm. I suggest updating the Makefile to use undionly.kkkpxe because of the change

On 24/10/15 21:57, Doug Scoular via Syslinux wrote: > 1. gpxe - a mothballed Network Boot Program but with a possibly problematic > and slow HTTP implementation. > 2. ipxe - an active fork of gpxe but still with the possibly problematic > and slow HTTP implementation (?) iPXE's HTTP implementation is definitely not slow. On a Gigabit LAN, you should get the full 1000Mbps speed

On Sat, Sep 26, 2015 at 1:59 PM, Gene Cumm <gene.cumm at gmail.com> wrote: > On Thu, Sep 24, 2015 at 6:59 AM, Gene Cumm <gene.cumm at gmail.com> wrote: >> On Thu, Sep 24, 2015 at 6:33 AM, Gene Cumm <gene.cumm at gmail.com> wrote: >> >>> Now I have something I can reproduce. Booting my same ipxe.iso to >>> perform an initial TFTP load shows what I

"H. Peter Anvin" <hpa at zytor.com> writes: > The gPXE in the Syslinux tree is ridiculously old. We could either > replace it with iPXE or just drop it, giving people a recipe for how to > integrate with iPXE themselves. > > What do people think? Do you mean a recipe for creating [gi]pxelinux.0 or for deploying iPXE and using pxelinux on top of that? Is there any

Hi, I try to exchange datas between host and Guest by adding these lines in a guest .xml conf file : <channel type='pty'> <target type='virtio' name='arbitrary.virtio.serial.port.name'/> <address type='virtio-serial' controller='0' bus='0' port='1'/> </channel> Then

In PXELinux 4.06 (the vanilla version, not gpxelinux.0), I'm trying to use pxechn.c32 to call iPXE (undionly) with option 67 set to call an iPXE script. The relevant portion of my PXELinux config looks like this: LABEL MDT MENU LABEL ^B - MDT 2012 SP1 com32 pxechn.c32 APPEND undionly.kpxe -o 67.s=ipxe/mdt.ipxe However iPXE doesn't seem to get the option correctly, it goes into

Hi, I found this message in your online mail archive, i have found the same problem and did some research in the past on this. Maybe you would be interested to know it is a problem on any virtualisation product not just ESX. Second it is a problem in gPXE that you embedded in gPXElinux. The problem was build in gPXE after version 0.97 so any gPXElinux build a newer version has this problem. I

IRC user ernini first noticed this. We both tried using gpxe/gpxelinux.0 from Syslinux-4.04-pre22. ernini used pxechain to a commercial NBP which RETs (the same as PXELINUX) and failed. Both of us had success with core/pxelinux.0 from Syslinux-4.04-pre22. For my test, I have a VM in VMware Server 2.0.2 (VMHW v7). I loaded gpxelinux.0 using the VM's built-in PXE ROM. Then I used

Hello, This is my first post. Please forgive me if I am not posting this in the right location. I work at a college where we clone staff computer every now and then. We have an internal network in our office. There is a Linux NAT, DHCP, PXE server in our office separating the two networks. Internally, we PXE with images that boot into Ghost to clone computers. We do not have access to the