search for: nonrelocatable

...kernel.org I run make spotless bios; make bios ./bios/extlinux/extlinux -i {target mounted partition} The extlinux partition contains both kernels, ldlinux.sys, ldlinux.c32 and extlinux.conf, which is PROMPT 1 LABEL 1 LINUX {relocatable vmlinuz} APPEND root={target partition} LABEL 2 LINUX {nonrelocatable vmlinuz} APPEND root={target partition} I've heard that the SeaBIOS on these machines may report an incorrect amount of memory, requiring (at least older versions of) syslinux to use/pass "mem=1500m" or some such on the APPEND line for some linux iso installers. As shown above,...

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

...that was a useful clue. I think I know what is going on. The > problem is that we're trying to make sure there is enough memory to > decompress the kernel, 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... Looks really good! This works for all my use cases. Thanks a lot and keep up the good work! -- main(a){char*c=/* Schoene Gruesse */"B?IJj;MEH" "CX:;",b;for(a/*...

> 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

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

...argument > OK, that was a useful clue. I think I know what is going on. The problem is that we're trying to make sure there is enough memory to decompress the kernel, 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...

...; ./bios/extlinux/extlinux -i {target mounted partition} > > The extlinux partition contains both kernels, ldlinux.sys, ldlinux.c32 and > extlinux.conf, which is > PROMPT 1 > LABEL 1 > LINUX {relocatable vmlinuz} > APPEND root={target partition} > LABEL 2 > LINUX {nonrelocatable vmlinuz} > APPEND root={target partition} > > I've heard that the SeaBIOS on these machines may report an incorrect > amount of memory, requiring (at least older versions of) syslinux to > use/pass "mem=1500m" or some such on the APPEND line for some linux iso &gt...