similar to: PATH directive searches in reverse order with wrong separator

On Tue, 11 Jun, at 03:54:21AM, H. Peter Anvin wrote: > On 06/11/2013 01:03 AM, Matt Fleming wrote: > > On Mon, 10 Jun, at 07:57:50AM, H. Peter Anvin wrote: > >> Either that or make the path a list rather than a string, using the > >> normal word separators when entered on the command line, a bit like the > >> (t)csh does. That is a bigger change but is probably

>From f48d79be8c79241dd4635165e393683809edd823 Mon Sep 17 00:00:00 2001 From: Matt Fleming <matt.fleming at intel.com> Date: Wed, 12 Jun 2013 13:04:44 +0100 Subject: [PATCH] PATH: Change the PATH directive syntax In retrospect, choosing the colon character as the entry separator for the PATH directive was not a smart move, as that character is also used in TFTP-style paths. This conflict

On 06/12/2013 09:40 AM, Matt Fleming wrote: > On Tue, 11 Jun, at 03:54:21AM, H. Peter Anvin wrote: >> On 06/11/2013 01:03 AM, Matt Fleming wrote: >>> On Mon, 10 Jun, at 07:57:50AM, H. Peter Anvin wrote: >>>> Either that or make the path a list rather than a string, using the >>>> normal word separators when entered on the command line, a bit like the

> I've been trying to get syslinux.efi working in my environment again... > > Found what look like a bunch of little bugs that are very frustrating... > > First, the documentation on the Wiki says that as of 5.11, the list > separator is space, not colon. But I can find no evidence that 5.11 > was ever officially released or that a commit to git was made to make >

From: Matt Fleming <matt.fleming at intel.com> The following patch series is available at, git://git.zytor.com/users/mfleming/syslinux.git elflink All patches are against the 'elflink' branch. This series fixes a few serious bugs and some behavioural incompatibilities with the 4.x series. Matt Fleming (19): ldlinux: Initialise 'p' before using it. ldlinux: Parse

On Wed, 12 Jun, at 11:17:44AM, Gerardo Exequiel Pozzi wrote: > Cool thanks!. Now looks better, but still not work. > > For some reason, "ldlinux.c32" is apparently sent but "Failed to load" > by PXELINUX and few seconds later, dnsmasq shows an error message > "failed sending": Argh! The patch was broken. I missed the new core/path.c file. My bad.

From: Gene Cumm <gene.cumm at gmail.com> COMBOOT API: Add get current working directory call to most (Revised) Signed-off-by: Gene Cumm <gene.cumm at gmail.com> --- Revised based on discussions on this list. Include trailing "/" on SYSLINUX and ISOLINUX. Copy TFTP Prefix as-is in PXELINUX. Initialize CurrentDirName to "./" in EXTLINUX (until a better solution

On Mon, 10 Jun, at 07:57:50AM, H. Peter Anvin wrote: > Either that or make the path a list rather than a string, using the > normal word separators when entered on the command line, a bit like the > (t)csh does. That is a bigger change but is probably a better solution. How would this solution handle filenames containing spaces? Would we need to escape (presumably with a backslash)

Hi, We are using pxelinux at my company to test our product. And there are limitations that we have hit in the past w.r.t. the max length of a path, or the max length of a module name (in mboot.c / mboot.c32). We've used workarounds in the past, and reorganized the directory structure, but we face that problem again. Out of the 128 / FILENAME_MAX chars that can be used, 110 - 120 go to the

From: Gene Cumm <gene.cumm at gmail.com> COMBOOT API: Add get current working directory call to most Signed-off-by: Gene Cumm <gene.cumm at gmail.com> --- Adds an API call to obtain the current working directory. EXTLINUX will not return the correct value yet however SYSLINUX, ISOLINUX, and PXELINUX will return the correct value. For the moment, EXTLINUX will ONLY return

From: Gene Cumm <gene.cumm at gmail.com> COMBOOT API: Add calls for directory functions; Implement most only for FAT (SYSLINUX). Uses INT 22h AX= 001Eh, 001Fh, 0020h and 0021h to prepare for the COM32 C functions getcwd(), opendir(), readdir(), and closedir(), respectively. INT22h, AX=001Eh will return a valid value for all variants. INT22h, AX= 001Fh, 0020h, and 0021h are only

On Wed, Oct 07, 2015 at 05:58:51PM -0500, Clements, James wrote: > James Clement > > Geert Stappers > > > On Wed, Oct 07, 2015 at 05:06:41PM -0500, Clements, James wrote: > > > > The screen displays the following: > > > > > > > > PXE Network Boot using IPv4 > > > > .... > > > > Station IP address is 192.168.205.50

Hi Peter, The main part of this pull request includes commits that try to replace as many __intcall() invocations as possible. Some remain, but not many (and eventually they'll be gone too). There's also a patch to make better use of ld's --as-needed option and various other bug fixes/cleanups. The following changes since commit ff7334a2ce536b7f4b1f6d6f93ff4e285a3bd45a: Only

At boot: prompt, COM32 module calls with full path fails silently. Please let me know if this is not the best fix for it. Also, please forgive me if this is not a bug and I did something wrong on my end. The following changes since commit 2779b713bdd8644ee2b52962ece6daa209b4ba6b: com32: remove duplicate modules (2012-05-22 20:59:51 -0300) are available in the git repository at:

From: Gene Cumm <gene.cumm at gmail.com> COMBOOT API: Add calls for directory functions; Implement most only for FAT (SYSLINUX). Uses INT 22h AX= 001Fh, 0020h, 0021h and 0022h to prepare for the COM32 C functions getcwd(), opendir(), readdir(), and closedir(), respectively. INT22h, AX=001Fh will return a valid value for all variants. INT22h, AX= 0020h, 0021h, and 0022h are only

Hi, These patches contain support for some features that are already in Syslinux 4 but weren't working properly on the elflink branch. It's another step closer to feature parity with Syslinux 4. Having to jump through the comboot API for localboot support is less than ideal and I'll eventually fix that, probably when we move a big chunk of code from asm to C. Also, there's a

DHCP seems to be working properly - returning the correct boot file for the architecture of the PXE client, but when I try to boot syslinux.efi, it gets the file then keeps requesting ldinux.e64 over and over again. The file is there and available. A wireshark trace shows it keeps requesting the file, followed by the server responding to the blksize and tsize options, but then the client just

Hi all, wasnt sure whether this was the best place to put this information; but something seems to have gone 'backwards' in the later pre-releases of 6.03 regarding network booting. below are results of me testing - i did each a few times to make sure they are valid results. hope it helps identify something that's gone awry ? so far, 6.03 pre11 and pre13 (excluding efi32) seem most

> DHCP seems to be working properly - returning the correct boot file for the > architecture of the PXE client, but when I try to boot syslinux.efi, it gets > the file then keeps requesting ldinux.e64 over and over again. The file is > there and available. A wireshark trace shows it keeps requesting the file, > followed by the server responding to the blksize and tsize options,

>> DHCP seems to be working properly - returning the correct boot file >> for the architecture of the PXE client, but when I try to boot >> syslinux.efi, it gets the file then keeps requesting ldinux.e64 over >> and over again. The file is there and available. A wireshark trace >> shows it keeps requesting the file, followed by the server responding to the