similar to: Changing the Reply-To: option for the list

On Mar 14, 2014 3:41 PM, "Ady" <ady-sf at hotmail.com> wrote: > > > > Hi all, > > > > A few years ago, at popular request, I changed the default of the list > > to have a Reply-To: pointing at the list. I personally find it very > > annoying, and I would like to change the default back. > > > > Would people object to trying it? >

Op 2014-03-14 om 16:02 schreef Gene Cumm: > On Mar 14, 2014 3:41 PM, "Ady" <ady-sf at hotmail.com> wrote: > > > > > > > Hi all, > > > > > > A few years ago, at popular request, I changed the default of the list > > > to have a Reply-To: pointing at the list. I personally find it very > > > annoying, and I would like to

> Hi all, > > A few years ago, at popular request, I changed the default of the list > to have a Reply-To: pointing at the list. I personally find it very > annoying, and I would like to change the default back. > > Would people object to trying it? > > -hpa Hi Peter, My assumption is that having a specific and adequate "reply-to" field reduces the

Hello, Here are some humble suggestions for 'doc/menu.txt' and 'doc/syslinux.txt'. They might be relevant for other documentation sources too. Unfortunately, I don't know how to prepare adequate patches. For 'menu.txt': _ Line 8: "located in the menu/ subdirectly." Suggestion: "located in the 'com32/cmenu' subdirectory." _ Line 10:

On Sat, Oct 6, 2012 at 5:48 AM, Ady <ady-sf at hotmail.com> wrote: > > Date sent: 06 Oct 2012 10:37:00 +0200 > From: Hullen at t-online.de (Helmut Hullen) > To: syslinux at zytor.com > Organization: Hullen BS > Subject: [syslinux] Error 0400 > Send reply to: helmut at hullen.de, >

works with legacy, hangs with efi. where works is: No DEFAULT or UI configuration directive found! but enter and ^v make things happen hangs is: nothing happens, no response from keyboard, have to reboot. note: config prompt.cfg prompt.cfg does not exist, but I would expect similar behaviour between efi and legacy. test is: starting with blank image, mkfs, mount it... + cp

On 15 dec. 2013, at 20:21, Ady <ady-sf at hotmail.com> wrote: Hi Ady, > Please forgive my ignorance. Could someone point to some "standard" > or some documentation where the supposedly correct / adequate value > (EE or ED or whichever) is specifically listed and/or explained? > > For example, where is this "ED" partition type ID listed where it >

On Nov 28, 2015 2:51 AM, "Ady via Syslinux" <syslinux at zytor.com> wrote: > > From: Sylvain Gault <sylvain.gault at gmail.com> > > > > The System V ABI for x86-64 specify that a "red zone" is an area of 128 bytes > > above the current stack frame. This area can be used by a called function in > > order to avoid the overhead of

> With respect to all of the actually important stuff however, I may have > missed it all, but I don't recall having read or seen an explanation of > what Ady & everybody else finally figured out about all this. What is > the answer, in the end? I did get the part about how (for my board, > at least) tweeking some of the info within the relevant MBR partition > table

> > kernel.c:new_linux_kernel() to load_linux.c:bios_boot_linux() because > > there is no convenient way in new_linux_kernel() to control the boot > > flags value. > > This is the part that has me questioning things and trying to recall > if any other KERNEL-like directives ever utilize keeppxe. > @Gene, Not being a developer myself, I don't understand this

> I'm testing syslinux PXE EFI boot with VMware workstation 9.04 running > on Windows 8.1 > > VMware correctly performs the DHCP request indicating either > the "EFI IA32" or "EFI BC" architecture and the TFTP server > correctly sends back w/o error the "corresponding" syslinux.efi > "EFI BC" -> EFI64\syslinux.efi >

Hi, first, thanks a lot, Ady and Gene, for your prompt and very useful replies! Ady wrote (11 Jun 2014 20:18:43 GMT) : > Although I haven't tested it lately, the Tuxboot tool should be able > to use the version of Syslinux included in your ISO images so to > transfer it to a (USB) drive. Since it works for other Debian-based > distros, it might answer to your needs.

On 06/15/2015 01:08 PM, Ady via Syslinux wrote: > > Example in repo.or.cz: > > tag name: > http://repo.or.cz/syslinux.git > /tag/refs/tags/syslinux-4.07 > > tag hash: > http://repo.or.cz/syslinux.git > /tag/a4fcb6d867aadcaf5af8f87eb1ba96abe2748159 > > If I understand correctly, the corresponding syntax for git.zytor.com > and kernel.org would

On Sat, Jun 13, 2015 at 10:44:11PM +0300, Ady via Syslinux wrote: > > > I'm starting this thread to discuss what git repository should be > > designated as primary and which repositories should be designated as > > secondary. > > > > For years, git.kernel.org has been the primary repo, updated at least > > with every full and pre- release.

I'm starting this thread to discuss what git repository should be designated as primary and which repositories should be designated as secondary. For years, git.kernel.org has been the primary repo, updated at least with every full and pre- release. git.zytor.com has been the secondary and development repo. Additionally, I've maintained my repos at github.com and git.zytor.com as

Just tested with the latest VirtualBox and that works OK, so it's definitely something specific to ESXi 6.0.0 (it worked previously under 5.x ESXi versions). Thanks, Dan Jackson (Lead ITServices Technician). -----Original Message----- From: Syslinux [mailto:syslinux-bounces at zytor.com] On Behalf Of Jackson, Dan via Syslinux Sent: 16 June 2016 09:27 To: 'syslinux at zytor.com'

> > Emphasize proper NASM versions. > > --- > NEWS | 4 ++++ > 1 file changed, 4 insertions(+) > > diff --git a/NEWS b/NEWS > index d1a5b2c..7848c6b 100644 > --- a/NEWS > +++ b/NEWS > @@ -2,6 +2,10 @@ Starting with 1.47, changes marked with SYSLINUX, PXELINUX, ISOLINUX > or EXTLINUX apply to that specific program only; other changes apply > to all

Hello, Thanks very much for your suggestions. I have double checked that all .c32 files are from the same version of syslinux. What I don't know - I only put those .c32 files I have in there on the basis of trial and error - is what .c32 files are actually needed for menu.c32 and/or vesamenu.c32. I thought perhaps there might be a .c32 file missing that I needed to put in there (though

Am 02.12.2014 schrieb Ady: > ( ... ) > > Since we are in the Syslinux Mailing List, please let me rephrase the > most relevant part of this case: syslinux.efi 6.03 is incapable of > booting some kernel, whereas syslinux.efi 6.01 can successfully boot it > under the same conditions. > I can now confirm that this can be replicated on hardware, a ThinkCentre M93 will reboot

On Fri, Jan 9, 2015 at 12:00 PM, Ady <ady-sf at hotmail.com> wrote: > >> I'm testing syslinux PXE EFI boot with VMware workstation 9.04 running >> on Windows 8.1 I use Syslinux 6.03 EFI64 on a VMware Workstation 10 VM on 10.0.2 on Linux. >> VMware correctly performs the DHCP request indicating either >> the "EFI IA32" or "EFI BC"