similar to: regression: relocatable kernels on a chromebook

> 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

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

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

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

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 Fri, 6 Feb 2015, Ady wrote: > ... > But if we are talking about Chromebooks with SeaBIOS, are we talking > about booting kernels in CSM mode? Or in UEFI mode? > > Other than Chromebooks with (stock) SeaBIOS, is this new reported > behavior also seen under other cases / hardware / firmware / kernels > (versions)? Hi Ady, With a clone of the git repo on kernel.org I run

Christian Hesse <list at eworm.de> on Tue, 2013/10/22 13:14: > Christian Hesse <list at eworm.de> on Tue, 2013/10/22 12:56: > > Gene Cumm <gene.cumm at gmail.com> on Tue, 2013/10/22 06:35: > > > On Tue, Oct 22, 2013 at 5:41 AM, Christian Hesse <list at eworm.de> wrote: > > > > Hello everybody, > > > > > > > > iPXE builds

> On Fri, 6 Feb 2015, Ady wrote: > > ... > > But if we are talking about Chromebooks with SeaBIOS, are we talking > > about booting kernels in CSM mode? Or in UEFI mode? > > > > Other than Chromebooks with (stock) SeaBIOS, is this new reported > > behavior also seen under other cases / hardware / firmware / kernels > > (versions)? > > Hi Ady,

> On Fri, 6 Feb 2015, Ady wrote: > ... > > Testing with public popular kernels that are known to work (so to > > compare the behavior) might be useful too, but I don't know of any > > particular kernels to suggest for such tests. > > Right, I've confirmed boot failure using CONFIG_RELOCATABLE with > unmodified Linux 3.12.24, 3.13, 3.15, 3.18, and

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

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 Fri, 6 Feb 2015, Ady wrote: ... > Testing with public popular kernels that are known to work (so to > compare the behavior) might be useful too, but I don't know of any > particular kernels to suggest for such tests. Right, I've confirmed boot failure using CONFIG_RELOCATABLE with unmodified Linux 3.12.24, 3.13, 3.15, 3.18, and 3.19-rc7 kernels. > I know that for

Hi, I am testing Google's recent ability to integrate Chromebooks into AD and it's failing when I try to join the device to the domain. When I run wireshark during the test I notice 2 TGS-REQs from the device that are answered with KRB5KDC_ERR_ETYPE_NOSUPP. The Chromebook is only passing AES256-cts-hmac-sha1-96 and AES128-cts-hmac-sha1-96 as enc types. I was getting the same result from

I ran both scripts last night and was able to get the Chromebook to join the domain this morning. Thanks, Achim! For posterity's sake, I should mention that I changed the user's password when I enabled AES on their Account tab, in ADUC. Thanks, Mike On Wed, Dec 27, 2017 at 9:52 AM, Achim Gottinger via samba < samba at lists.samba.org> wrote: > Hello Mike, > > Can be you

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

Hello Mike, Can be you need to recreate the machine and tgt password on yout server so it adds the aes enc types for these after raising the functional domai level. The required scripts can be found in tthe samba sources in /source4/scripting/devel/ Use chdcpass for the machine-account and chgkrbtgtpass for the tgt account. I did this on an single addc server a while back and had no issues.

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 >> commit 8f470e7bfe75f6401f6c5432988c620b863ad274 Author: Matt >> Fleming <matt.fleming at intel.com> Date:

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