multiboot2 and module2 boot issues via GRUB2

multiboot2 and module2 boot issues via GRUB2

[Roman Shaposhnik]

[-- Attachment #1: Type: text/plain, Size: 750 bytes --]

Hi!

seems like I've run into an issue with multiboot2 and module2
commands that I can't quite explain. Since it may be something
super simply and silly -- I wanted to reach out here before I do
a GRUB/Xen/LK source deepdive.

So here's the deal: whenever I boot straight up Linux kernel
I can do the following sequence of commands:
   linux /kernel
   initrd foo.cpio.gz bar.cpio.gz
and have linux kernel effectively stack content of bar.cpio.gz
on top of foo.cpio.gz and present a unified initramfs that way.

I'm trying to replicate it with Xen, but:
     multiboot2 /boot/xen.gz
     module2 /kernel
     module2 foo.cpio.gz
     module2 bar.cpio.gz
only seems to be picking up foo.cpio.gz

Has anyone run into this issue before?

Thanks,
Roman.

[-- Attachment #2: Type: text/html, Size: 1095 bytes --]

Re: multiboot2 and module2 boot issues via GRUB2

[Andrew Cooper]

On 30/03/2021 19:28, Roman Shaposhnik wrote:
> Hi!
>
> seems like I've run into an issue with multiboot2 and module2
> commands that I can't quite explain. Since it may be something
> super simply and silly -- I wanted to reach out here before I do
> a GRUB/Xen/LK source deepdive.
>
> So here's the deal: whenever I boot straight up Linux kernel
> I can do the following sequence of commands:
>    linux /kernel
>    initrd foo.cpio.gz bar.cpio.gz
> and have linux kernel effectively stack content of bar.cpio.gz
> on top of foo.cpio.gz and present a unified initramfs that way.
>
> I'm trying to replicate it with Xen, but:
>      multiboot2 /boot/xen.gz
>      module2 /kernel
>      module2 foo.cpio.gz
>      module2 bar.cpio.gz
> only seems to be picking up foo.cpio.gz
>
> Has anyone run into this issue before?

I can explain why that happens.  Not sure if it counts as a feature, bug
or mis-expectation, but CC'ing grub-devel for their input.

The initrd command is presumably concatenating those two files together
in memory, and presenting Linux a single initrd pointer.

For the module2 example, you're putting 3 distinct files in memory, and
giving Xen a list 3 modules.

Xen is capable of taking various things via modules, such as an
XSM/Flask policy, or microcode, so has logic to identify these if
present and separate them from "other stuff".  However, there is a
hardcoded expectation that the first module is the dom0 kernel, and the
next unrecognised module, if present, is *the* initrd.

I expect that Xen isn't handing bar.cpio.gz on to dom0, but I'm not sure
whether passing two distinct initrd-like-things to Linux is even possible.

What you presumably want is some `initrd` side effect in Grub so you can
write `module2 foo.cpio.gz bar.cpio.gz` and have it concatenate things
together in memory and present one MB2 module, but I suspect that exact
syntax might be ambiguous with command line handling.  I have no idea
whether such a command currently exists.

~Andrew

Re: multiboot2 and module2 boot issues via GRUB2

[Roman Shaposhnik]

[-- Attachment #1: Type: text/plain, Size: 2732 bytes --]

Hi Andrew!

first of all -- thanks for pointing me in the right direction. So after
reading relevant sources: comments inline.

On Tue, Mar 30, 2021 at 12:08 PM Andrew Cooper <andrew.cooper3@citrix.com>
wrote:

> On 30/03/2021 19:28, Roman Shaposhnik wrote:
> > Hi!
> >
> > seems like I've run into an issue with multiboot2 and module2
> > commands that I can't quite explain. Since it may be something
> > super simply and silly -- I wanted to reach out here before I do
> > a GRUB/Xen/LK source deepdive.
> >
> > So here's the deal: whenever I boot straight up Linux kernel
> > I can do the following sequence of commands:
> >    linux /kernel
> >    initrd foo.cpio.gz bar.cpio.gz
> > and have linux kernel effectively stack content of bar.cpio.gz
> > on top of foo.cpio.gz and present a unified initramfs that way.
> >
> > I'm trying to replicate it with Xen, but:
> >      multiboot2 /boot/xen.gz
> >      module2 /kernel
> >      module2 foo.cpio.gz
> >      module2 bar.cpio.gz
> > only seems to be picking up foo.cpio.gz
> >
> > Has anyone run into this issue before?
>
> I can explain why that happens.  Not sure if it counts as a feature, bug
> or mis-expectation, but CC'ing grub-devel for their input.
>
> The initrd command is presumably concatenating those two files together
> in memory, and presenting Linux a single initrd pointer.
>

It is indeed what seems to be happening.


> For the module2 example, you're putting 3 distinct files in memory, and
> giving Xen a list 3 modules.
>

And that is also correct -- nothing like that is possible with modules.
Kernel actually needs to be aware of them. So the question then
becomes...


> Xen is capable of taking various things via modules, such as an
> XSM/Flask policy, or microcode, so has logic to identify these if
> present and separate them from "other stuff".  However, there is a
> hardcoded expectation that the first module is the dom0 kernel, and the
> next unrecognised module, if present, is *the* initrd.

I expect that Xen isn't handing bar.cpio.gz on to dom0, but I'm not sure
> whether passing two distinct initrd-like-things to Linux is even possible.
>
> What you presumably want is some `initrd` side effect in Grub so you can
> write `module2 foo.cpio.gz bar.cpio.gz` and have it concatenate things
> together in memory and present one MB2 module, but I suspect that exact
> syntax might be ambiguous with command line handling.  I have no idea
> whether such a command currently exists.
>

...I guess there's no mechanism out-of-the box to achieve what I want?

And the obvious next question: is my EVE usecase esoteric enough that
I should just go ahead and do a custom GRUB patch or is there a more
general interest in this?

Thanks,
Roman.

[-- Attachment #2: Type: text/html, Size: 3949 bytes --]

Re: multiboot2 and module2 boot issues via GRUB2

[Jan Beulich]

On 01.04.2021 03:06, Roman Shaposhnik wrote:
> And the obvious next question: is my EVE usecase esoteric enough that
> I should just go ahead and do a custom GRUB patch or is there a more
> general interest in this?

Not sure if it ought to be a grub patch - the issue could as well
be dealt with in Xen, by concatenating modules to form a monolithic
initrd.

Jan

Re: multiboot2 and module2 boot issues via GRUB2

[Roger Pau Monné]

On Thu, Apr 01, 2021 at 09:31:07AM +0200, Jan Beulich wrote:
> On 01.04.2021 03:06, Roman Shaposhnik wrote:
> > And the obvious next question: is my EVE usecase esoteric enough that
> > I should just go ahead and do a custom GRUB patch or is there a more
> > general interest in this?
> 
> Not sure if it ought to be a grub patch - the issue could as well
> be dealt with in Xen, by concatenating modules to form a monolithic
> initrd.

I would rather have it done in the loader than Xen, mostly because
it's a Linux boot specific format, and hence I don't think Xen should
have any knowledge about it.

If it turns out to be impossible to implement on the loader side we
should consider doing it in Xen, but that's not my first option.

Thanks, Roger.

Re: multiboot2 and module2 boot issues via GRUB2

[Krystian Hebel]

On 01.04.2021 10:44, Roger Pau Monné via Grub-devel wrote:
> On Thu, Apr 01, 2021 at 09:31:07AM +0200, Jan Beulich wrote:
>> On 01.04.2021 03:06, Roman Shaposhnik wrote:
>>> And the obvious next question: is my EVE usecase esoteric enough that
>>> I should just go ahead and do a custom GRUB patch or is there a more
>>> general interest in this?
>> Not sure if it ought to be a grub patch - the issue could as well
>> be dealt with in Xen, by concatenating modules to form a monolithic
>> initrd.
> I would rather have it done in the loader than Xen, mostly because
> it's a Linux boot specific format, and hence I don't think Xen should
> have any knowledge about it.
Keep in mind that loader is loading Xen, using multiboot2 which is kind of
generic boot protocol, not Linux with its specific protocol. There may be
other multiboot2 kernels that depend on modules being _not_ concatenated,
such change would most likely break those.

Best regards,

-- 
Krystian Hebel
Firmware Engineer
https://3mdeb.com | @3mdeb_com

> If it turns out to be impossible to implement on the loader side we
> should consider doing it in Xen, but that's not my first option.
>
> Thanks, Roger.
>
> _______________________________________________
> Grub-devel mailing list
> Grub-devel@gnu.org
> https://lists.gnu.org/mailman/listinfo/grub-devel

Re: multiboot2 and module2 boot issues via GRUB2

[Andrew Cooper]

On 01/04/2021 09:44, Roger Pau Monné wrote:
> On Thu, Apr 01, 2021 at 09:31:07AM +0200, Jan Beulich wrote:
>> On 01.04.2021 03:06, Roman Shaposhnik wrote:
>>> And the obvious next question: is my EVE usecase esoteric enough that
>>> I should just go ahead and do a custom GRUB patch or is there a more
>>> general interest in this?
>> Not sure if it ought to be a grub patch - the issue could as well
>> be dealt with in Xen, by concatenating modules to form a monolithic
>> initrd.
> I would rather have it done in the loader than Xen, mostly because
> it's a Linux boot specific format, and hence I don't think Xen should
> have any knowledge about it.
>
> If it turns out to be impossible to implement on the loader side we
> should consider doing it in Xen, but that's not my first option.

Concatenating random things which may or may not be initrds is
absolutely not something Xen should do.  We don't have enough context to
do it safely/sensibly.

Honestly, I like the idea of supporting something like this generally in
grub.  Linux already commonly has initrd preparation prepending an
uncompressed microcode CPIO archive, and I can see a usability advantage
from maintaining the initrd fragments separately.

Looking at the grub manual, this behaviour of the `initrd` command isn't
even documented.  Perhaps that should be fixed first, and then maybe
`module2_multi` added too?

~Andrew

Re: multiboot2 and module2 boot issues via GRUB2

[Jan Beulich]

On 01.04.2021 21:43, Andrew Cooper wrote:
> On 01/04/2021 09:44, Roger Pau Monné wrote:
>> On Thu, Apr 01, 2021 at 09:31:07AM +0200, Jan Beulich wrote:
>>> On 01.04.2021 03:06, Roman Shaposhnik wrote:
>>>> And the obvious next question: is my EVE usecase esoteric enough that
>>>> I should just go ahead and do a custom GRUB patch or is there a more
>>>> general interest in this?
>>> Not sure if it ought to be a grub patch - the issue could as well
>>> be dealt with in Xen, by concatenating modules to form a monolithic
>>> initrd.
>> I would rather have it done in the loader than Xen, mostly because
>> it's a Linux boot specific format, and hence I don't think Xen should
>> have any knowledge about it.
>>
>> If it turns out to be impossible to implement on the loader side we
>> should consider doing it in Xen, but that's not my first option.
> 
> Concatenating random things which may or may not be initrds is
> absolutely not something Xen should do.  We don't have enough context to
> do it safely/sensibly.

Well, I wasn't suggesting anywhere to concatenate random things.
Instead I was envisioning a command line option giving us the
context we need (e.g. "initrd=3+5").

Jan

Re: multiboot2 and module2 boot issues via GRUB2

[Roman Shaposhnik]

[-- Attachment #1: Type: text/plain, Size: 1529 bytes --]

On Tue, Apr 6, 2021 at 1:19 AM Jan Beulich <jbeulich@suse.com> wrote:

> On 01.04.2021 21:43, Andrew Cooper wrote:
> > On 01/04/2021 09:44, Roger Pau Monné wrote:
> >> On Thu, Apr 01, 2021 at 09:31:07AM +0200, Jan Beulich wrote:
> >>> On 01.04.2021 03:06, Roman Shaposhnik wrote:
> >>>> And the obvious next question: is my EVE usecase esoteric enough that
> >>>> I should just go ahead and do a custom GRUB patch or is there a more
> >>>> general interest in this?
> >>> Not sure if it ought to be a grub patch - the issue could as well
> >>> be dealt with in Xen, by concatenating modules to form a monolithic
> >>> initrd.
> >> I would rather have it done in the loader than Xen, mostly because
> >> it's a Linux boot specific format, and hence I don't think Xen should
> >> have any knowledge about it.
> >>
> >> If it turns out to be impossible to implement on the loader side we
> >> should consider doing it in Xen, but that's not my first option.
> >
> > Concatenating random things which may or may not be initrds is
> > absolutely not something Xen should do.  We don't have enough context to
> > do it safely/sensibly.
>
> Well, I wasn't suggesting anywhere to concatenate random things.
> Instead I was envisioning a command line option giving us the
> context we need (e.g. "initrd=3+5").
>

That's actually not a bad idea at all -- I may look into how feasible it
would
be to add on Xen side. GRUB side is trivial (but I'm not sure upstream folks
would take it).

Thanks,
Roman.

[-- Attachment #2: Type: text/html, Size: 2061 bytes --]

Re: multiboot2 and module2 boot issues via GRUB2

[Andrew Cooper]

On 06/04/2021 09:19, Jan Beulich wrote:
> On 01.04.2021 21:43, Andrew Cooper wrote:
>> On 01/04/2021 09:44, Roger Pau Monné wrote:
>>> On Thu, Apr 01, 2021 at 09:31:07AM +0200, Jan Beulich wrote:
>>>> On 01.04.2021 03:06, Roman Shaposhnik wrote:
>>>>> And the obvious next question: is my EVE usecase esoteric enough that
>>>>> I should just go ahead and do a custom GRUB patch or is there a more
>>>>> general interest in this?
>>>> Not sure if it ought to be a grub patch - the issue could as well
>>>> be dealt with in Xen, by concatenating modules to form a monolithic
>>>> initrd.
>>> I would rather have it done in the loader than Xen, mostly because
>>> it's a Linux boot specific format, and hence I don't think Xen should
>>> have any knowledge about it.
>>>
>>> If it turns out to be impossible to implement on the loader side we
>>> should consider doing it in Xen, but that's not my first option.
>> Concatenating random things which may or may not be initrds is
>> absolutely not something Xen should do.  We don't have enough context to
>> do it safely/sensibly.
> Well, I wasn't suggesting anywhere to concatenate random things.
> Instead I was envisioning a command line option giving us the
> context we need (e.g. "initrd=3+5").

That's a massive layering violation, and incredibly fragile to the order
of lines in the boot stanza.

Either fix it by using a single monolithic initrd, which has worked
perfectly well for the past 2 decades, or add a feature to grub to get
initrd-like behaviour for MB2 too.  I will object very strongly to any
Xen patches trying to do this.

~Andrew

Re: multiboot2 and module2 boot issues via GRUB2

[Roman Shaposhnik]

[-- Attachment #1: Type: text/plain, Size: 2541 bytes --]

On Tue, Apr 6, 2021 at 10:51 AM Andrew Cooper <andrew.cooper3@citrix.com>
wrote:

> On 06/04/2021 09:19, Jan Beulich wrote:
> > On 01.04.2021 21:43, Andrew Cooper wrote:
> >> On 01/04/2021 09:44, Roger Pau Monné wrote:
> >>> On Thu, Apr 01, 2021 at 09:31:07AM +0200, Jan Beulich wrote:
> >>>> On 01.04.2021 03:06, Roman Shaposhnik wrote:
> >>>>> And the obvious next question: is my EVE usecase esoteric enough that
> >>>>> I should just go ahead and do a custom GRUB patch or is there a more
> >>>>> general interest in this?
> >>>> Not sure if it ought to be a grub patch - the issue could as well
> >>>> be dealt with in Xen, by concatenating modules to form a monolithic
> >>>> initrd.
> >>> I would rather have it done in the loader than Xen, mostly because
> >>> it's a Linux boot specific format, and hence I don't think Xen should
> >>> have any knowledge about it.
> >>>
> >>> If it turns out to be impossible to implement on the loader side we
> >>> should consider doing it in Xen, but that's not my first option.
> >> Concatenating random things which may or may not be initrds is
> >> absolutely not something Xen should do.  We don't have enough context to
> >> do it safely/sensibly.
> > Well, I wasn't suggesting anywhere to concatenate random things.
> > Instead I was envisioning a command line option giving us the
> > context we need (e.g. "initrd=3+5").
>
> That's a massive layering violation, and incredibly fragile to the order
> of lines in the boot stanza.
>

Don't have enough karma to argue Xen architectural side of things, but...


> Either fix it by using a single monolithic initrd, which has worked
> perfectly well for the past 2 decades
>

...just to point out the obvious here:  even Debian who can HARDLY be
blamed for tracking the bleeding edge has been recommending this
for quite some time:

https://wiki.debian.org/DebianInstaller/NetbootFirmware#The_Solution:_Add_Firmware_to_Initramfs
Obviously there's no way to do that with Xen today out of the box.

Now, you can turn around and say "well, how hard could it be to
concatenate?". That's fair. But it is also fair to point out that everytime
we do that we portray Xen as "not quite as user friendly as X" (and
this is, of course, pure perception -- but if we want users to stick
perception matters a lot).

Thanks,
Roman.

P.S. Curiously enough, saying that -- I'm undermining my own case -- it is
actually
*easier* for me to hack GRUB in EVE. But I felt like stating the obvious
anyway.

[-- Attachment #2: Type: text/html, Size: 3585 bytes --]

Re: multiboot2 and module2 boot issues via GRUB2

[Andrew Cooper]

[-- Attachment #1: Type: text/plain, Size: 3988 bytes --]

On 06/04/2021 19:03, Roman Shaposhnik wrote:
> On Tue, Apr 6, 2021 at 10:51 AM Andrew Cooper
> <andrew.cooper3@citrix.com <mailto:andrew.cooper3@citrix.com>> wrote:
>
>     On 06/04/2021 09:19, Jan Beulich wrote:
>     > On 01.04.2021 21:43, Andrew Cooper wrote:
>     >> On 01/04/2021 09:44, Roger Pau Monné wrote:
>     >>> On Thu, Apr 01, 2021 at 09:31:07AM +0200, Jan Beulich wrote:
>     >>>> On 01.04.2021 03:06, Roman Shaposhnik wrote:
>     >>>>> And the obvious next question: is my EVE usecase esoteric
>     enough that
>     >>>>> I should just go ahead and do a custom GRUB patch or is
>     there a more
>     >>>>> general interest in this?
>     >>>> Not sure if it ought to be a grub patch - the issue could as well
>     >>>> be dealt with in Xen, by concatenating modules to form a
>     monolithic
>     >>>> initrd.
>     >>> I would rather have it done in the loader than Xen, mostly because
>     >>> it's a Linux boot specific format, and hence I don't think Xen
>     should
>     >>> have any knowledge about it.
>     >>>
>     >>> If it turns out to be impossible to implement on the loader
>     side we
>     >>> should consider doing it in Xen, but that's not my first option.
>     >> Concatenating random things which may or may not be initrds is
>     >> absolutely not something Xen should do.  We don't have enough
>     context to
>     >> do it safely/sensibly.
>     > Well, I wasn't suggesting anywhere to concatenate random things.
>     > Instead I was envisioning a command line option giving us the
>     > context we need (e.g. "initrd=3+5").
>
>     That's a massive layering violation, and incredibly fragile to the
>     order
>     of lines in the boot stanza.
>
>
> Don't have enough karma to argue Xen architectural side of things, but...
>  
>
>     Either fix it by using a single monolithic initrd, which has worked
>     perfectly well for the past 2 decades
>
>
> ...just to point out the obvious here:  even Debian who can HARDLY be
> blamed for tracking the bleeding edge has been recommending this
> for quite some time:
>  
>   https://wiki.debian.org/DebianInstaller/NetbootFirmware#The_Solution:_Add_Firmware_to_Initramfs
> <https://wiki.debian.org/DebianInstaller/NetbootFirmware#The_Solution:_Add_Firmware_to_Initramfs>
> Obviously there's no way to do that with Xen today out of the box.

?

Those instructions do work out of the box with Xen.

It seems that pxelinux gained support for multiple initrd fragments in
3.05, but the sum total of documentation I can find is in the
changelog.  iPXE might have this ability, but it's documentation is
self-contradictory on the matter.

>
> Now, you can turn around and say "well, how hard could it be to
> concatenate?". That's fair. But it is also fair to point out that
> everytime
> we do that we portray Xen as "not quite as user friendly as X" (and
> this is, of course, pure perception -- but if we want users to stick
> perception matters a lot).

It's distinctly not trivial to do correctly at the Xen level, and fairly
invasive in at least two areas of logic.  Specific firmware layouts and
multiple fragments might even be impossible to concatenate, and its
better for the bootloaders to bail if they can't make the memory layout
work, than to leave Xen holding the the pieces and unable to boot. 
Either way, it would appear that common bootloaders already have logic
for this, which gets you a lot further than starting from scratch in Xen.


Furthermore, I don't think it fair to claim that this is a usability bug
in Xen, when what the Linux people have done is upstream Linux-specific
hacks to bootloaders.  Fixing the bootloaders to not have useful
features be Linux specific benefits everyone using Multiboot, not just
the Xen ecosystem.  If you're looking for general betterness to all OSS,
then fixing the bootloaders is clearly the better approach.

~Andrew

[-- Attachment #2: Type: text/html, Size: 6532 bytes --]

Re: multiboot2 and module2 boot issues via GRUB2

[Glenn Washburn]

On Thu, 1 Apr 2021 20:43:46 +0100
Andrew Cooper via Grub-devel <grub-devel@gnu.org> wrote:

> On 01/04/2021 09:44, Roger Pau Monné wrote:
> > On Thu, Apr 01, 2021 at 09:31:07AM +0200, Jan Beulich wrote:
> >> On 01.04.2021 03:06, Roman Shaposhnik wrote:
> >>> And the obvious next question: is my EVE usecase esoteric enough
> >>> that I should just go ahead and do a custom GRUB patch or is
> >>> there a more general interest in this?
> >> Not sure if it ought to be a grub patch - the issue could as well
> >> be dealt with in Xen, by concatenating modules to form a monolithic
> >> initrd.
> > I would rather have it done in the loader than Xen, mostly because
> > it's a Linux boot specific format, and hence I don't think Xen
> > should have any knowledge about it.
> >
> > If it turns out to be impossible to implement on the loader side we
> > should consider doing it in Xen, but that's not my first option.
> 
> Concatenating random things which may or may not be initrds is
> absolutely not something Xen should do.  We don't have enough context
> to do it safely/sensibly.
> 
> Honestly, I like the idea of supporting something like this generally
> in grub.  Linux already commonly has initrd preparation prepending an
> uncompressed microcode CPIO archive, and I can see a usability
> advantage from maintaining the initrd fragments separately.
> 
> Looking at the grub manual, this behaviour of the `initrd` command
> isn't even documented.  Perhaps that should be fixed first, and then
> maybe `module2_multi` added too?

If you mean that the concatenation of multiple initrds by the `initrd`
command isn't documented (not sure that's the behavior your'r referring
to), it actually has been recently documented (by me) and is in master.
You're probably looking at the last release (2.04) documentation, in
which it is indeed not documented. This should change soon after
release and the documentation gets updated accordingly.

Glenn

Re: multiboot2 and module2 boot issues via GRUB2

[Daniel Kiper]

On Thu, Apr 01, 2021 at 08:43:46PM +0100, Andrew Cooper via Grub-devel wrote:
> On 01/04/2021 09:44, Roger Pau Monné wrote:
> > On Thu, Apr 01, 2021 at 09:31:07AM +0200, Jan Beulich wrote:
> >> On 01.04.2021 03:06, Roman Shaposhnik wrote:
> >>> And the obvious next question: is my EVE usecase esoteric enough that
> >>> I should just go ahead and do a custom GRUB patch or is there a more
> >>> general interest in this?
> >> Not sure if it ought to be a grub patch - the issue could as well
> >> be dealt with in Xen, by concatenating modules to form a monolithic
> >> initrd.
> > I would rather have it done in the loader than Xen, mostly because
> > it's a Linux boot specific format, and hence I don't think Xen should
> > have any knowledge about it.
> >
> > If it turns out to be impossible to implement on the loader side we
> > should consider doing it in Xen, but that's not my first option.
>
> Concatenating random things which may or may not be initrds is
> absolutely not something Xen should do.  We don't have enough context to
> do it safely/sensibly.
>
> Honestly, I like the idea of supporting something like this generally in
> grub.  Linux already commonly has initrd preparation prepending an
> uncompressed microcode CPIO archive, and I can see a usability advantage
> from maintaining the initrd fragments separately.
>
> Looking at the grub manual, this behaviour of the `initrd` command isn't
> even documented.  Perhaps that should be fixed first, and then maybe
> `module2_multi` added too?

I am OK with additional Multiboot2 command. Though I would do
s/module2_multi/module2_concat/. Additionally, it should look for "--"
and interpret everything after it as a command line argument for
a concatenated module.

Daniel

Re: multiboot2 and module2 boot issues via GRUB2

[Elliott Mitchell]

On Tue, Mar 30, 2021 at 11:28:49AM -0700, Roman Shaposhnik wrote:
> seems like I've run into an issue with multiboot2 and module2
> commands that I can't quite explain. Since it may be something
> super simply and silly -- I wanted to reach out here before I do
> a GRUB/Xen/LK source deepdive.
> 
> So here's the deal: whenever I boot straight up Linux kernel
> I can do the following sequence of commands:
>    linux /kernel
>    initrd foo.cpio.gz bar.cpio.gz
> and have linux kernel effectively stack content of bar.cpio.gz
> on top of foo.cpio.gz and present a unified initramfs that way.
> 
> I'm trying to replicate it with Xen, but:
>      multiboot2 /boot/xen.gz
>      module2 /kernel
>      module2 foo.cpio.gz
>      module2 bar.cpio.gz
> only seems to be picking up foo.cpio.gz
> 
> Has anyone run into this issue before?

Not I, but I asked questions elsewhere before I fought this battle.  You
should get a more recent version of GRUB.

More recent versions of GRUB (2.04) on ARM have the "xen_hypervisor" boot
mode.  With this boot mode the kernel and initrd get passed via
xen_module command.

Apparently newer GRUB versions have better boot methods for Xen, so
updating would be a Good Idea, if that is viable for you.


-- 
(\___(\___(\______          --=> 8-) EHM <=--          ______/)___/)___/)
 \BS (    |         ehem+sigmsg@m5p.com  PGP 87145445         |    )   /
  \_CS\   |  _____  -O #include <stddisclaimer.h> O-   _____  |   /  _/
8A19\___\_|_/58D2 7E3D DDF4 7BA6 <-PGP-> 41D1 B375 37D0 8714\_|_/___/5445

Re: multiboot2 and module2 boot issues via GRUB2

[Bruno]

[-- Attachment #1: Type: text/plain, Size: 294 bytes --]

Hello folks.

Thank you for this. I a incurring the same problem, can’t boot into Xen.

Did anyone implement the grub2 patch? Is there any way around this?

I have posted it on stackexchange with more details and the config files:

https://unix.stackexchange.com/q/710400/375983



[-- Attachment #2: Type: text/html, Size: 605 bytes --]