similar to: [PATCH] load_linux: correct a type

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

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

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

Some kernel images use the Linux kernel boot protocol and header structure, but do not actually have any protected-mode code. For instance, grub's 1024-byte lnxboot.img consists of 1024 real-mode bytes and 0 protected-mode bytes; you can concatenate it with a full grub core.img to produce a self-contained bootable kernel, but you can also use it standalone as the kernel with the core.img

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

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

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

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

These patches fix a few compiler warnings. Tested on top of commit aee0dc5565711ef5be7c30fb5fc1c5f3f98db09f Jonathan Boeing (6): Use z width specifier when printing size_t variable pxe: fix truncation warning gpllib: fix sizeof(char *) misuse hdt: fix sizeof(char *) misuse hdt: fix sizeof(char *) misuse hdt: fix sizeof(char *) misuse com32/gpllib/dmi/dmi.c | 24 +++---

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

"syslinux-bot for H. Peter Anvin" <hpa at zytor.com> on Wed, 2013/12/04 12:39: > Commit-ID: ef81a3ad54845ffb5ad62714cd62db4740ad5cff > Gitweb: > 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>

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

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

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

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