search for: load_linux

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 --- a/com32/lib/syslinux/load_linux.c +++ b/com32/lib/syslinux/load_linux.c @@ -155,8 +155,8 @@ int bios_boot_linux(void *kernel_...

...start location, random code is executed and the machine is rebooted. Restore the old behavior by assigning prot_mode_base the value of base. Tested on a machine that exposed this behavior. Signed-off-by: Scot Doyle <lkml14 at scotdoyle.com> --- This patch may be applied in addition to "load_linux: correct a type" com32/lib/syslinux/load_linux.c | 1 + 1 file changed, 1 insertion(+) diff --git a/com32/lib/syslinux/load_linux.c b/com32/lib/syslinux/load_linux.c index 06ae2a9..5cecef4 100644 --- a/com32/lib/syslinux/load_linux.c +++ b/com32/lib/syslinux/load_linux.c @@ -323,6 +323,7 @@...

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

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

On 07/26/2013 01:27 AM, syslinux-bot for Matt Fleming wrote: > diff --git a/com32/lib/syslinux/load_linux.c b/com32/lib/syslinux/load_linux.c > index 851d467..37c8df0 100644 > --- a/com32/lib/syslinux/load_linux.c > +++ b/com32/lib/syslinux/load_linux.c > @@ -125,10 +125,29 @@ static int map_initramfs(struct syslinux_movelist **fraglist, > } > > static size_t calc_cmdline_offse...

...in. 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 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. In basic testing, keeppxe seems to work with the patch applied. --- syslinux-6.04-pre1.orig/com32/elflink/ldlinux/kernel.c 2016-03-01 21:06:02.000000000 -0800 +++ syslinux-6.04-pre1/co...

...itweb: > http://www.syslinux.org/commit/ef81a3ad54845ffb5ad62714cd62db4740ad5cff > Author: H. Peter Anvin <hpa at zytor.com> AuthorDate: Wed, 4 Dec 2013 > 12:35:09 -0800 Committer: H. Peter Anvin <hpa at zytor.com> > CommitDate: Wed, 4 Dec 2013 12:37:55 -0800 > > load_linux: Don't use size heuristic for non-relocatable kernels > > For non-relocatable kernels, it really makes no sense to estimate how > much space the kernel is going to need, as if we fail, there is really > nothing we can do about it. Furthermore, it is actively wrong for > zImage...

...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 > 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. > > In basic testing, keeppxe seems to work with the patch applied. > > > --- syslinux-6.04-pre1.orig/com32/elflink/ldlinux/kernel.c 2016-03-01 21:06:02.000000...

Hi, back in February, Scot Doyle proposed two patches: http://www.syslinux.org/archives/2015-February/023209.html http://www.syslinux.org/archives/2015-February/023179.html Since then, the bug fixed by those patches has been identified in Ubuntu, Debian and Tails: https://bugs.launchpad.net/ubuntu/+source/syslinux/+bug/1429323 https://bugs.debian.org/780765

On Sun, Aug 9, 2015 at 3:44 AM, intrigeri via Syslinux <syslinux at zytor.com> wrote: > Hi, > > back in February, Scot Doyle proposed two patches: > > http://www.syslinux.org/archives/2015-February/023209.html 0a2dbb339 > http://www.syslinux.org/archives/2015-February/023179.html 83aad4f6 -- -Gene

Impact: None. The end of memory needs to be page aligned: if the initrd expands beyond it, Linux kernels won't be able to access the last few bytes. Signed-off-by: Pierre-Alexandre Meyer <pierre at mouraf.org> --- com32/lib/syslinux/load_linux.c | 2 +- 1 files changed, 1 insertions(+), 1 deletions(-) diff --git a/com32/lib/syslinux/load_linux.c b/com32/lib/syslinux/load_linux.c index b772056..d09a2cb 100644 --- a/com32/lib/syslinux/load_linux.c +++ b/com32/lib/syslinux/load_linux.c @@ -292,7 +292,7 @@ int syslinux_boot_linux(void *k...

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 example memory map where this would be a problem? I not sure I understand what

Hi there, ----- Original Message ----- From: koxudaxi at gmail.com To: syslinux at zytor.com Date: 01.04.2013 10:00:27 Subject: Re: [syslinux] Problem with pxelinux 5.0 and memtest > On 04/01/2013 09:28 AM, H. Peter Anvin wrote: >> On 03/31/2013 05:26 PM, Koudai Aono wrote: >>> I ran the test on a x86 emulator is called Oracle VirtualBox. >>> I think it might not be

...ies to the "elflink" branch for syslinux 5. Found because people started trying to use syslinux 5 to boot BITS, which uses lnxboot.img as kernel and core.img as initrd, and it failed to boot with the mysterious "Bad file descriptor" message mentioned above. com32/lib/syslinux/load_linux.c | 18 +++++++++++------- 1 files changed, 11 insertions(+), 7 deletions(-) diff --git a/com32/lib/syslinux/load_linux.c b/com32/lib/syslinux/load_linux.c index 471d8a5..04a5210 100644 --- a/com32/lib/syslinux/load_linux.c +++ b/com32/lib/syslinux/load_linux.c @@ -324,7 +324,8 @@ int syslinux_b...

...el, which isn't relevant for a zImage (the memory is decompressed into high memory) and arguably isn't relevant for a nonrelocatable kernel. I have attached a patch (completely untested) which might fix this... -hpa -------------- next part -------------- diff --git a/com32/lib/syslinux/load_linux.c b/com32/lib/syslinux/load_linux.c index df934e40cd83..06ae2a976619 100644 --- a/com32/lib/syslinux/load_linux.c +++ b/com32/lib/syslinux/load_linux.c @@ -124,32 +124,29 @@ static int map_initramfs(struct syslinux_movelist **fraglist, return 0; } -static size_t calc_cmdline_offset(struct l...

...2). >> If even that is no good do nothing. >> >> Any suggestions as to how to implement the requirement ? > > A custom COM32 module. Look at ifcpu.c32 for an example of an if-else > module and the crypto functions in com32/util/ > Or we could make the Linux loader (load_linux.c) throw an error on a bad CRC, which is probably a good idea anyway. Then the ONERROR option can be used for the fallback. -hpa

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

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

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? syslinux_run_command (lib/syslinu...

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