search for: mcb30

...pxelinux.cfg/default > >> set 210:string http://some_server_elsewere/ > >> chain ${210:string}pxelinux.0 > > pxelinux.0 loads but fail to load menu (pxelinux.cfg/default). The following patch to syslinux for core/fs/pxe/pxe.c (also available at http://git.ipxe.org/people/mcb30/syslinux.git/commitdiff/9126eb2) fixes this problem for me. I am not 100% sure about the error handling in __pxe_searchdir(), so would appreciate some review. Michael commit 9126eb27d1d9597eb8751a5ef75c9bdcf4e429a6 Author: Michael Brown <mcb30 at ipxe.org> Date: Mon Mar 28 20:44:17 20...

Trivial module to execute an arbitrary command. --- com32/modules/Makefile | 2 +- com32/modules/cmd.c | 42 ++++++++++++++++++++++++++++++++++++++++++ 2 files changed, 43 insertions(+), 1 deletions(-) create mode 100644 com32/modules/cmd.c diff --git a/com32/modules/Makefile b/com32/modules/Makefile index 2739a39..930e89b 100644 --- a/com32/modules/Makefile +++ b/com32/modules/Makefile

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. --

Hello Peter, the following changes since commit 0620743d1e54cf48aa8e5cf5636739addae49d60: H. Peter Anvin (1): Merge remote-tracking branch 'mcb30/empty-tftp-ip' are available in the git repository at: git://repo.or.cz/syslinux/sherbszt.git gfxboot32 Sebastian Herbszt (4): gfxboot: use skipspace() gfxboot: don't use the bounce buffer gfxboot: remove lowmem_buf_size variable gfxboot: remove save_read() func...

On 30/08/14 02:00, Gene Cumm wrote: >> And then in the same location, I put this boot.ipxe file and all support >> files: >> >> #!ipxe >> kernel wimboot >> initrd bootmgr bootmgr >> initrd boot/bcd BCD >> initrd boot/boot.sdi boot.sdi >> initrd http://<SCCM-server>/boot.wim boot.wim >>

On Sat, Aug 30, 2014 at 6:40 AM, Michael Brown <mcb30 at ipxe.org> wrote: > and then just invoke wimboot as a UEFI binary (_not_ as a Linux kernel). I > don't know the configuration file syntax for this, sorry. > > Michael My understanding is that at this time there's no method to load an EFI binary from Syslinux. http://bug...

...interrupt at the PIC, some will crash the machine due to single-bit errors in the ISR address. When PXENV_UNDI_ISR_IN_START returns PXENV_UNDI_ISR_OUT_NOT_OURS, send the EOI ourselves rather than risking the unpredictable behaviour of chaining to the original ISR. Signed-off-by: Michael Brown <mcb30 at ipxe.org> --- core/fs/pxe/isr.c | 5 +++-- core/fs/pxe/pxe.h | 1 - core/pxeisr.inc | 17 ++++++----------- 3 files changed, 9 insertions(+), 14 deletions(-) diff --git a/core/fs/pxe/isr.c b/core/fs/pxe/isr.c index 7da0cc7..e14b953 100644 --- a/core/fs/pxe/isr.c +++ b/core/fs/pxe/isr.c...

On 30/08/15 12:10, Gene Cumm via Syslinux wrote: > Those should produce debug text listing the original PxeBc handle and > its full MAC then proceed to list the UDPv4Sb handles and their MACs. > I'm still trying to figure out if there's a way to get the handle > numbers that the shells use. I looked into this for iPXE. From memory, it wasn't easily possible: the shell

On 02/03/16 22:47, Patrick Masotta via Syslinux wrote: > Not really, a virtual environment can easily emulate the BIOS_timer at 0x046C > but it has problems emulating a "real" timer interrupt to be hooked... > That's the real problem. The timer interrupt works fine in at least KVM, Xen, VMware, and Hyper-V. (I've tested iPXE in all of those virtual environments, and

...ssion timeout later (approximately three seconds). This can increase the time taken by lpxelinux.0 to fetch its configuration file from a few milliseconds to around 30 seconds. Fix by immediately retransmitting the SYN whenever a half-open connection is detected. Signed-off-by: Michael Brown <mcb30 at ipxe.org> --- core/lwip/src/core/tcp_in.c | 3 +++ 1 file changed, 3 insertions(+) diff --git a/core/lwip/src/core/tcp_in.c b/core/lwip/src/core/tcp_in.c index 9095264..d410dab 100644 --- a/core/lwip/src/core/tcp_in.c +++ b/core/lwip/src/core/tcp_in.c @@ -675,6 +675,9 @@ tcp_process(struct...

On 28/08/14 19:38, Jason Jones wrote: > Anyone have luck with pxechn32 and bootmgfw.efi? > > I'm getting the "Unable to retrieve first package" issue as reported by others. > > Really, any advice for UEFI booting into a winpe environment off of pxelinux 6.03 would be beneficial. As it happens, I released a new version of wimboot with support for UEFI yesterday. The

...may end up downloading an incorrect file (e.g. attempting to download pxelinux.cfg/default but actually receiving a copy of ldlinux.c32, due to the port number having been reused). Fix by allocating local UDP port numbers in the same way as local TCP port numbers. Signed-off-by: Michael Brown <mcb30 at ipxe.org> --- core/lwip/src/core/udp.c | 57 ++++++++++++++++++++++++++++-------------------- 1 file changed, 33 insertions(+), 24 deletions(-) diff --git a/core/lwip/src/core/udp.c b/core/lwip/src/core/udp.c index 4596ba2..68e7f48 100644 --- a/core/lwip/src/core/udp.c +++ b/core/lwip/src/c...

> Date: Fri, 29 Aug 2014 13:02:10 +0100 > From: Michael Brown <mcb30 at ipxe.org> > To: Jason Jones <jason.s.jones at convergys.com>, "syslinux at zytor.com" > <syslinux at zytor.com> > Subject: Re: [syslinux] PXE booting WinPE with UEFI architecture > Message-ID: <54006BC2.3090703 at ipxe.org> > Content-Type: te...

Anyone have luck with pxechn32 and bootmgfw.efi? I'm getting the "Unable to retrieve first package" issue as reported by others. Really, any advice for UEFI booting into a winpe environment off of pxelinux 6.03 would be beneficial. Jason Jones Sr. Associate, Network Services | End User Computing 3947 N Oak St Ext | Valdosta, GA 31605 O +15137844955 E jason.s.jones at

...D,boot.sdi,winpe.wim TEXT HELP Deployment of Operating System via SCCM. Jason Jones Sr. Associate, Network Services | End User Computing 3947 N Oak St Ext | Valdosta, GA 31605 O +15137844955 E jason.s.jones at convergys.com -----Original Message----- From: Michael Brown [mailto:mcb30 at ipxe.org] Sent: Friday, August 29, 2014 8:02 AM To: Jason Jones; syslinux at zytor.com Subject: Re: [syslinux] PXE booting WinPE with UEFI architecture On 28/08/14 19:38, Jason Jones wrote: > Anyone have luck with pxechn32 and bootmgfw.efi? > > I'm getting the "Unable to retri...

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 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 03/03/16 07:31, Patrick Masotta wrote: > > The timer interrupt works fine in at least KVM, Xen, VMware, and > > Hyper-V. (I've tested iPXE in all of those virtual environments, and > > iPXE relies on the timer interrupt actually triggering a call to an ISR > > within the VM.) > > Well, that contradicts what the VMware document says. How so? Michael

On 03/03/16 09:18, Patrick Masotta wrote: >>>> How so? > > it says they cannot emulate the timer interrupt very well; > that's what I understood... If it's the VMware document I'm thinking of (titled "Timekeeping in VMware Virtual Machines"), then the issue is that emulating the timer interrupt can cause a heavy load on the host if the guest timer is

On 03/03/16 09:34, Patrick Masotta wrote: > > If it's the VMware document I'm thinking of (titled "Timekeeping in > > VMware Virtual Machines"), then the issue is that emulating the timer > > interrupt can cause a heavy load on the host if the guest timer is > > configured to run at a high rate. > > It seems it's more that that even at the