similar to: [PATCH] (vesa)menu.c32: Add support for BLS

Displaying 20 results from an estimated 500 matches similar to: "[PATCH] (vesa)menu.c32: Add support for BLS"

2019 May 25
2
[PATCH] (vesa)menu.c32: Add support for BLS
On Sat, May 25, 2019 at 3:42 PM Sebastian Herbszt <herbszt at gmx.de> wrote: > > Gregory Lee Bartholomew wrote: > > Modern distributions are moving toward a common boot scheme called > > "The Boot Loader Specification". > > Which distributions are using this yet? > > > This patch enables syslinux's > > (vesa)menu.c32 modules to parse the
2019 Jul 09
0
[PATCH] core: Add support for BLS Type 1 entries
Modern distributions are moving toward a common boot scheme called "The Boot Loader Specification". This patch enables syslinux to parse the drop-in files that are defined by this new specification. Link to documentation of the options added to syslinux by this patch: https://drive.google.com/uc?export=download&id=1nuRISVJeE1whYggFURywoQFpPzc6s1MC MD5 (syslinux-bls1.txt) =
2019 May 25
0
[PATCH] (vesa)menu.c32: Add support for BLS
Gregory Lee Bartholomew wrote: > Modern distributions are moving toward a common boot scheme called > "The Boot Loader Specification". Which distributions are using this yet? > This patch enables syslinux's > (vesa)menu.c32 modules to parse the drop-in files that are defined by > this new specification. Any reason why you don't try to implement this in syslinux
2019 May 27
0
[PATCH] (vesa)menu.c32: Add support for BLS
Gregory Bartholomew wrote: > On Sat, May 25, 2019 at 3:42 PM Sebastian Herbszt <herbszt at gmx.de> > wrote: > > > > Gregory Lee Bartholomew wrote: > > > Modern distributions are moving toward a common boot scheme called > > > "The Boot Loader Specification". > > > > Which distributions are using this yet? [copy & paste from other
2011 May 25
1
[GIT PULL] elflink ldlinux
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
2011 Mar 09
14
[PATCH 00/12] elflink shrinkage
From: Matt Fleming <matt.fleming at linux.intel.com> This is a series of patches that, * shrink the core by moving things into an ldlinux ELF module * begin wiring up some of the C versions of various functions The core now only contains essential code and loads the ldlinux module to do everything else, like providing a command line interface and loading kernels. The config file parsing
2013 Jun 12
3
[5.10] PXE + dhcp opts 209, 210 and path issues in tftp/http
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.
2012 May 04
3
[GIT PULL] elflink fixes
Peter, Paulo reported some problems with his config files under ISOLINUX and PXELINUX - basically TIMEOUT and TOTALTIMEOUT were broken. The patches I've pushed to the elflink branch fix this and also fix parsing of the ALLOWOPTIONS config directive. The following changes since commit d5e02fb16a11bfdbce1e90a39e6cb5f2ad925389: get_key: Valid key values are positive (2012-04-17 11:25:53
2013 Jun 11
2
[5.10] PXE + dhcp opts 209, 210 and path issues in tftp/http
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)
2013 Jun 12
5
[5.10] PXE + dhcp opts 209, 210 and path issues in tftp/http
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
2016 Jun 29
0
Fwd: [PATCH] {vesa}menu.c32 feature => hide menu entry for specific sources
good afternoon. As promised to Mr Cumm few weeks before, I forward you the mail that I had wrongly sent directly to Mr Anvin. This is something I've done for my company usage and I submit it to you. Feel free to include it if you think this can be usefull for others .. Context: In my company, we have several distinct PXE server (depending on the location: europe, asia, ....). each of these
2013 Jun 24
2
[bug] Syslinux-5.11-pre2: IPAPPEND/SYSAPPEND inconsistent base
core and the simple menu do not interpret the IPAPPEND/SYSAPPEND directives in the same way. Which is the proper way? Either way, this should be clarified in the documentation. com32/elflink/ldlinux/readconfig.c: } else if ((ep = looking_at(p, "ipappend")) || (ep = looking_at(p, "sysappend"))) { uint32_t s = strtoul(skipspace(ep), NULL,
2013 Jun 24
2
[5.11-pre1] SYSAPPEND does not work (IPAPPEND alias works)
On Sun, Jun 23, 2013 at 3:16 PM, Gerardo Exequiel Pozzi <vmlinuz386 at yahoo.com.ar> wrote: > I guess the bug is here (com32/menu/readconfig.c) > > 910 } else if (looking_at(p, "ipappend") || looking_at(p, > "sysappend")) { > 911 if (ld.label) > 912 ld.ipappend = atoi(skipspace(p + 8)); > 913
2013 Jun 24
2
[bug] Syslinux-5.11-pre2: IPAPPEND/SYSAPPEND inconsistent base
On Sun, Jun 23, 2013 at 11:09 PM, Gene Cumm <gene.cumm at gmail.com> wrote: > On Sun, Jun 23, 2013 at 11:06 PM, Gene Cumm <gene.cumm at gmail.com> wrote: >> core and the simple menu do not interpret the IPAPPEND/SYSAPPEND >> directives in the same way. Which is the proper way? Either way, >> this should be clarified in the documentation. > > To be clear:
2013 Jun 14
2
[5.11-pre1] SYSAPPEND does not work (IPAPPEND alias works)
On 06/13/2013 10:15 PM, Gene Cumm wrote: > On Thu, Jun 13, 2013 at 8:08 PM, Gerardo Exequiel Pozzi > <vmlinuz386 at yahoo.com.ar> wrote: >> Hello >> >> While testing PXE booting, I decided to change IPAPPEND to the new >> SYSAPPEND and does not work: nothing is appended to command line. >> >> I tested using menu.c32 and vesamenu.c32, same issue.
2016 Apr 22
4
PXERETRY directive
Would someone please be so kind to explain / describe the PXERETRY directive? TIA, Ady.
2016 Apr 27
2
PXERETRY directive
On Wed, Apr 27, 2016 at 06:23:38AM -0400, Gene Cumm via Syslinux wrote: > On Thu, Apr 21, 2016 at 10:30 PM, Ady via Syslinux <syslinux at zytor.com> wrote: > > Would someone please be so kind to explain / describe the PXERETRY > > directive? > > $ git grep -ni pxeretry -i ignore case ("thanks" said the person who exact case matching search ) >
2013 Jun 12
0
[5.10] PXE + dhcp opts 209, 210 and path issues in tftp/http
>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
2016 Apr 27
4
PXERETRY directive
> On Thu, Apr 21, 2016 at 10:30 PM, Ady via Syslinux <syslinux at zytor.com> wrote: > > Would someone please be so kind to explain / describe the PXERETRY > > directive? > > $ git grep -ni pxeretry > com32/elflink/ldlinux/readconfig.c:1305: else if (looking_at(p, "pxeretry")) > com32/elflink/ldlinux/readconfig.c:1306: PXERetry = >
2013 Jun 12
0
[5.10] PXE + dhcp opts 209, 210 and path issues in tftp/http
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