similar to: [PATCH] Fix support for Linux kernel images with no protected mode code

On 12/04/2013 12:38 AM, Christian Hesse wrote: > > Sure. Here we go: > > boot: debug -e bios_boot_linux calc_cmdline_offset > boot: ipxe.lkrn > Loading ipxe.lkrn... ok > cmdline_offset at 0x9f7e0 > Initial memory map: > Could not find location for protected-mode code > Booting kernel failed: Invalid argument > OK, that was a useful clue. I think I know what is

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

If the kernel is relocatable and the protected mode code will not fit in the initially determined location, that code will be moved to the next available location. However, beginning with commit 8f470e7b, the code is moved to the initially determined location instead of the next available location because prot_mode_base is no longer updated to the correct location. Since whdr->code32_start is

This patch is just a (shameless) copy from bug #28 [1]. The original patch has been sitting there for a couple of years now, and it was based on Syslinux v 4.05. The patch I am posting here is just a re-base on v.6.03. Whichever inadequate formatting (tabs, trailing spaces...), or any kind of correction that was required for the original patch to be accepted, is probably still required now.

On Fri, Jun 10, 2016 at 2:06 AM, Adam Goldman via Syslinux <syslinux at zytor.com> wrote: > 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,

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

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

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

> On Sat, 7 Feb 2015, Ady via Syslinux wrote: > > Thank you for this meaningful report. Ideally, I would suggest > > performing a similar test (at least with the same kernel built with all > > the above "config_*=y" settings) with official pre-built Syslinux > > versions 4.07 and 3.86 (remembering that all Syslinux-related files, > > including c32

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

Hello I want to fallback to a second boot entry, if the kernel is missing for the first entry. So I through I could use ONERROR, but syslinux just continue to try starting the first entry. Am I doing something wrong? or can't this be done with syslinux? default menu.c32 prompt 0 MENU HIDDEN MENU AUTOBOOT TIMEOUT 2 ONERROR live-generic label grub ??? menu label ^Grub ??? menu default

On Sun, 8 Feb 2015, Ady wrote: ... > There have been discussions and/or reports somewhat related to this > matter during 2013 (Mar-Dec), and reports about failing to boot some > kernels with Syslinux 6.03 (2014Q4). > > The topics involved: > > _ Kernels with no protected-mode code (e.g. grub's kernel lnxboot.img > initrd=core.img) > _ bzImage and zImage files

On Fri, Feb 20, 2015 at 8:08 AM, Patrick Masotta via Syslinux <syslinux at zytor.com> wrote: > This patch adds to the core EFI image booting capabilities. > It was tested on VMware EFI clients and HP Elitebook EFI notebooks, > only on PXE environments but it should work on non-PXE scenarios as well. > > Feedback appreciated. If you've made any changes to this, I'd

> 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 I appreciate the replies. Hopefully someone might be able to come up with some contribution / answer. The Syslinux code has already received at some point some patches regarding the EFI

A Toshiba CB35 Chromebook running Google's stock SeaBIOS reboots after selecting a relocatable kernel from extlinux 6.03. This is a regression caused by commit 8f470e7b movebits: Add syslinux_memmap_find() which factors syslinux_memmap_find() out of bios_boot_linux(). Prior to the refactoring, prot_mode_size was passed as the length in the first call to syslinux_memmap_type(). After

> A Toshiba CB35 Chromebook running Google's stock SeaBIOS reboots after > selecting a relocatable kernel from extlinux 6.03. > > This is a regression caused by commit 8f470e7b > movebits: Add syslinux_memmap_find() > > which factors syslinux_memmap_find() out of bios_boot_linux(). Prior to > the refactoring, prot_mode_size was passed as the length in the first

I have just pushed out Syslinux 3.80-pre7. I am slightly concerned about putting this into the release tree at this point: I was working with some of the shuffler code, and found that the memory map handling was actually severely buggy on some of my test cases. Resolving that problem took rewriting most of syslinux_add_memmap(). However, against better judgement :) I decided to check in the

On Sat, 7 Feb 2015, Ady via Syslinux wrote: > Thank you for this meaningful report. Ideally, I would suggest > performing a similar test (at least with the same kernel built with all > the above "config_*=y" settings) with official pre-built Syslinux > versions 4.07 and 3.86 (remembering that all Syslinux-related files, > including c32 modules, if being used, shall

This patch adds to the core EFI image booting capabilities. It was tested on VMware EFI clients and HP Elitebook EFI notebooks, only on PXE environments but it should work on non-PXE scenarios as well. Feedback appreciated. Best, Patrick Signed-off-by: Patrick Masotta <masottaus at yahoo.com> --- diff -uprN a/com32/elflink/ldlinux/execute.c b/com32/elflink/ldlinux/execute.c ---

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?