similar to: Problem with pxelinux 5.0 and memtest

Hello, This is my first post to this list. After searching through the archives and google searches I could not find a solution for my memtest problem. In previous versions of pxelinux/gpxelinux (4.04 and 4.06) I could successfully start the memtest utility. But using pxelinux/gpxelinux versions 5.01 and 5.02 the memtest utility does not boot and I get an error message: boot: Loading

Hi >On Wed, 24 Jul, at 03:48:14PM, Matt Fleming wrote: >> On Wed, 24 Jul, at 09:04:17PM, Victor Sudakov wrote: >> > memtest86 does not work any more after upgrading PXELINUX to 6.01. >> > When trying to boot, I get the following message: >> > >> > PXELINUX 6.01 2013-07-04 Copyright (C) 1994-2013 H. Peter Anvin et al >> > Loading memtest86...

On 2013.08.10 04:07, H. Peter Anvin wrote: >> My application already its own version of the Syslinux installer [1], >> and simply requires the relevant ldlinux.sys file to be provided. > > But that, too, is version-specific. I think there may be a misunderstanding here. Are you saying that when installing ldlinux.sys + ldlinux.bss v5.01 on a FAT filesystem, the installer needs

Correct base's type to match its initialization from prot_mode_base and passage to syslinux_memmap_find(). Tested with extlinux. Signed-off-by: Scot Doyle <lkml14 at scotdoyle.com> --- com32/lib/syslinux/load_linux.c | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/com32/lib/syslinux/load_linux.c b/com32/lib/syslinux/load_linux.c index 06ae2a9..ac73729 100644 ---

PXELINUX has stopped recognizing the keeppxe option on the kernel command line. Here is a patch to make it work again. With COM32, it is no longer possible to use preprocessor directives to determine the SYSLINUX variant. The code inside the #if will never be compiled. So, I changed it to use syslinux_filesystem() to determine the variant. Also, I moved the relevant code from

On 07/29/2013 06:28 AM, Matt Fleming wrote: > On Fri, 26 Jul, at 09:49:28AM, H. Peter Anvin wrote: >> Hmm... this might constrain the heap excessively if the SMT_TERMINAL >> cutoff is at the wrong place (because there will be just enough SMT_FREE >> to fit.) I'm wondering if we shouldn't use the highest of these two >> regions. > > Could you give an

Hi, in syslinux-386, I think I've found a problem in com32/lib/syslinux/load_linux.c that leads to cmdline being truncated unnecessarily when e.g. linux.c32 is used. The patch below fixes the problem for me. But I don't know, whether the patch is safe in all cases. I tried to reproduce the logic found in runkernel.inc, but I might have missed something. So, feel free to tell me

"H. Peter Anvin" <hpa at zytor.com> on Tue, 2013/12/03 20:26: > On 10/24/2013 01:09 AM, Christian Hesse wrote: > >>> > >>> version 6.02-pre5 works, 6.02-pre6 does not. > >> > >> Struggled with git bisect, but finally succeeded: > >> > >> 8f470e7bfe75f6401f6c5432988c620b863ad274 is the first bad commit > >>

On 03/19/2014 01:30 PM, Gene Cumm wrote: > On Wed, Mar 19, 2014 at 4:16 PM, Mau Z <zmau1962 at gmail.com> wrote: >> Hi, >> >> I am wondering how to implement the following customer's requirement : >> The system is a stand alone embedded system with no operator (with Linux). >> There is one SSD for the system's usage (and that is where the system loads

On Mon, Jul 1, 2013 at 5:54 AM, Matt Fleming <matt at console-pimps.org> wrote: > On Sun, 30 Jun, at 12:56:32PM, Gene Cumm wrote: >> The following changes since commit d44ea657666e3a34d3859fc7262185e24c0b40fe: >> Matt Fleming (1): >> Merge tag 'syslinux-5.11-pre3' into firmware >> >> are available in the git repository at: >> >>

On Thu, Feb 2, 2017 at 1:26 PM, Ady Ady via Syslinux <syslinux at zytor.com> wrote: > > > Hi all, > > > > I have observed a problem where, under legacy BIOS booting mode on the > > DL360g9, memdisk fails to execute. The same mechanism works fine on the > > DL360g8. The system displays the below on the console and ceases to > > respond and must be

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

On Mon, Nov 23, 2015 at 3:06 PM, Ady via Syslinux <syslinux at zytor.com> wrote: > It saddens (me) > C'mon; really? As you asked. -- -Gene

On 08/10/2013 08:02 AM, Pete Batard wrote: > On 2013.08.10 04:07, H. Peter Anvin wrote: >>> My application already its own version of the Syslinux installer [1], >>> and simply requires the relevant ldlinux.sys file to be provided. >> >> But that, too, is version-specific. > > I think there may be a misunderstanding here. > > Are you saying that when

On 2013.08.10 01:55, H. Peter Anvin wrote: >> I assume it's not possible to store a copy of the LDLINUX.SYS binary at >> the end or inside of either ISOLINUX.BIN > > Not really. ldlinux.sys isn't just an ordinary file, it really needs to > be installed with the Syslinux installer. My application already its own version of the Syslinux installer [1], and simply

gfxboot uses those three calls, but currently doesn't really handle returns from them. syslinux_boot_linux (lib/syslinux/load_linux.c) can return ("bail" label). syslinux_local_boot (lib/syslinux/localboot.c) has a comment which says "returns only on failure". The documentation for "Local boot" in doc/comboot.txt says "Does not return". Which is correct?

Hi, I'm the author of Rufus [1], an application that is based in part on Syslinux, and that can convert ISOLINUX based ISOs to bootable USBs. As such, I have recently added support for Syslinux v5.x based ISOs, and will be looking at adding v6 support in the future. Due to the nature of the app, as well as obvious space considerations, when installing Syslinux 5.x on an USB flash drive,

Hi! On x86_64, changeset 18081, running/building on rhel5, trying to use the HVM direct boot causes the domain to reboot immediately and then the log says the domain is restarting too rapidly. No obvious hints as to where the problem is. If I build the in-tree ioemu code, things work. Any clues as to where to look or how to get some useful debugging output? Thanks, John Byrne

> On Tue, Jun 14, 2016 at 12:33 PM, Ady via Syslinux <syslinux at zytor.com> wrote: > > > >> > 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

Hi folks, Syslinux 5.01 is out, a week later than predicted but that's largely down to the realloc() bug described below. This release is mainly a collection of bug fixes for problems reported after people tested Syslinux 5.00. The NEWS entries are included at the bottom. There was a pretty nasty realloc() bug that took some time to find and fix, which resulted in memory corruption. There