doesn't have a
corresponding field so e820_map seems good enough. Thanks for working
through this.
Here's the revised patch
>From d46c75b4a9151c10e7f7809637f9f42a2c393c25 Mon Sep 17 00:00:00 2001
From: Andrew Jeddeloh <andrew.jedde...@coreos.com>
Date: Tue, 8 May 2018 14:39:01 -070
params.
Calculate the size of the header, rather than assume it is the size of
the linux_params struct.
Signed-off-by: Andrew Jeddeloh <andrew.jedde...@coreos.com>
---
grub-core/loader/i386/linux.c | 11 ++-
1 file changed, 10 insertions(+), 1 deletion(-)
diff --git a/grub-core/loade
hat I understand what's
supposed to be happening first.
Thanks,
- Andrew
On Wed, Apr 25, 2018 at 1:59 AM, Daniel Kiper <dki...@net-space.pl> wrote:
> On Tue, Apr 24, 2018 at 04:08:57PM -0700, Andrew Jeddeloh wrote:
>> Thanks for the reply.
>>
>> I'm not sure I
ue, Apr 24, 2018 at 5:56 AM, Daniel Kiper <dki...@net-space.pl> wrote:
> On Thu, Apr 19, 2018 at 03:22:55PM -0700, Andrew Jeddeloh wrote:
>> While solving a bug in the coreos fork of grub I came across this disk
>> read in the i386 linux loader [1]. It looks like its reading what
While solving a bug in the coreos fork of grub I came across this disk
read in the i386 linux loader [1]. It looks like its reading whatever
is after the boot param header in the kernel file (defined by the
linux x86 boot protocol [2]) into the rest of the `linux_params`
struct. In practice this
While solving a bug in the coreos fork of grub I came across this disk
read in the i386 linux loader [1]. It looks like its reading whatever
is after the boot param header in the kernel file (defined by the
linux x86 boot protocol [2]) into the rest of the `linux_params`
struct. In practice this
