* multiboot2 and module2 boot issues via GRUB2 @ 2021-03-30 18:28 Roman Shaposhnik 2021-03-30 19:08 ` Andrew Cooper 2021-03-30 19:35 ` Elliott Mitchell 0 siblings, 2 replies; 14+ messages in thread From: Roman Shaposhnik @ 2021-03-30 18:28 UTC (permalink / raw) To: Xen-devel [-- 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 --] ^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: multiboot2 and module2 boot issues via GRUB2 2021-03-30 18:28 multiboot2 and module2 boot issues via GRUB2 Roman Shaposhnik @ 2021-03-30 19:08 ` Andrew Cooper 2021-04-01 1:06 ` Roman Shaposhnik 2021-03-30 19:35 ` Elliott Mitchell 1 sibling, 1 reply; 14+ messages in thread From: Andrew Cooper @ 2021-03-30 19:08 UTC (permalink / raw) To: Roman Shaposhnik, Xen-devel, grub-devel 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 ^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: multiboot2 and module2 boot issues via GRUB2 2021-03-30 19:08 ` Andrew Cooper @ 2021-04-01 1:06 ` Roman Shaposhnik 2021-04-01 7:31 ` Jan Beulich 0 siblings, 1 reply; 14+ messages in thread From: Roman Shaposhnik @ 2021-04-01 1:06 UTC (permalink / raw) To: Andrew Cooper; +Cc: Xen-devel, grub-devel [-- 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 --] ^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: multiboot2 and module2 boot issues via GRUB2 2021-04-01 1:06 ` Roman Shaposhnik @ 2021-04-01 7:31 ` Jan Beulich 2021-04-01 8:44 ` Roger Pau Monné 0 siblings, 1 reply; 14+ messages in thread From: Jan Beulich @ 2021-04-01 7:31 UTC (permalink / raw) To: Roman Shaposhnik; +Cc: Xen-devel, grub-devel, Andrew Cooper 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 ^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: multiboot2 and module2 boot issues via GRUB2 2021-04-01 7:31 ` Jan Beulich @ 2021-04-01 8:44 ` Roger Pau Monné 2021-04-01 19:43 ` Andrew Cooper 0 siblings, 1 reply; 14+ messages in thread From: Roger Pau Monné @ 2021-04-01 8:44 UTC (permalink / raw) To: Jan Beulich; +Cc: Roman Shaposhnik, Xen-devel, grub-devel, Andrew Cooper 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. ^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: multiboot2 and module2 boot issues via GRUB2 2021-04-01 8:44 ` Roger Pau Monné @ 2021-04-01 19:43 ` Andrew Cooper 2021-04-06 8:19 ` Jan Beulich ` (2 more replies) 0 siblings, 3 replies; 14+ messages in thread From: Andrew Cooper @ 2021-04-01 19:43 UTC (permalink / raw) To: Roger Pau Monné, Jan Beulich; +Cc: Roman Shaposhnik, Xen-devel, grub-devel 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 ^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: multiboot2 and module2 boot issues via GRUB2 2021-04-01 19:43 ` Andrew Cooper @ 2021-04-06 8:19 ` Jan Beulich 2021-04-06 17:37 ` Roman Shaposhnik 2021-04-06 17:51 ` Andrew Cooper 2021-04-07 20:50 ` Glenn Washburn 2021-04-08 16:48 ` Daniel Kiper 2 siblings, 2 replies; 14+ messages in thread From: Jan Beulich @ 2021-04-06 8:19 UTC (permalink / raw) To: Andrew Cooper Cc: Roman Shaposhnik, Xen-devel, grub-devel, Roger Pau Monné 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 ^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: multiboot2 and module2 boot issues via GRUB2 2021-04-06 8:19 ` Jan Beulich @ 2021-04-06 17:37 ` Roman Shaposhnik 2021-04-06 17:51 ` Andrew Cooper 1 sibling, 0 replies; 14+ messages in thread From: Roman Shaposhnik @ 2021-04-06 17:37 UTC (permalink / raw) To: Jan Beulich; +Cc: Andrew Cooper, Xen-devel, grub-devel, Roger Pau Monné [-- 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 --] ^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: multiboot2 and module2 boot issues via GRUB2 2021-04-06 8:19 ` Jan Beulich 2021-04-06 17:37 ` Roman Shaposhnik @ 2021-04-06 17:51 ` Andrew Cooper 2021-04-06 18:03 ` Roman Shaposhnik 1 sibling, 1 reply; 14+ messages in thread From: Andrew Cooper @ 2021-04-06 17:51 UTC (permalink / raw) To: Jan Beulich; +Cc: Roman Shaposhnik, Xen-devel, grub-devel, Roger Pau Monné 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 ^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: multiboot2 and module2 boot issues via GRUB2 2021-04-06 17:51 ` Andrew Cooper @ 2021-04-06 18:03 ` Roman Shaposhnik 2021-04-06 18:41 ` Andrew Cooper 0 siblings, 1 reply; 14+ messages in thread From: Roman Shaposhnik @ 2021-04-06 18:03 UTC (permalink / raw) To: Andrew Cooper; +Cc: Jan Beulich, Xen-devel, grub-devel, Roger Pau Monné [-- 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 --] ^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: multiboot2 and module2 boot issues via GRUB2 2021-04-06 18:03 ` Roman Shaposhnik @ 2021-04-06 18:41 ` Andrew Cooper 0 siblings, 0 replies; 14+ messages in thread From: Andrew Cooper @ 2021-04-06 18:41 UTC (permalink / raw) To: Roman Shaposhnik; +Cc: Jan Beulich, Xen-devel, grub-devel, Roger Pau Monné [-- 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 --] ^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: multiboot2 and module2 boot issues via GRUB2 2021-04-01 19:43 ` Andrew Cooper 2021-04-06 8:19 ` Jan Beulich @ 2021-04-07 20:50 ` Glenn Washburn 2021-04-08 16:48 ` Daniel Kiper 2 siblings, 0 replies; 14+ messages in thread From: Glenn Washburn @ 2021-04-07 20:50 UTC (permalink / raw) To: Andrew Cooper via Grub-devel Cc: Roger Pau Monné, Jan Beulich, Andrew Cooper, Roman Shaposhnik, Xen-devel 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 ^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: multiboot2 and module2 boot issues via GRUB2 2021-04-01 19:43 ` Andrew Cooper 2021-04-06 8:19 ` Jan Beulich 2021-04-07 20:50 ` Glenn Washburn @ 2021-04-08 16:48 ` Daniel Kiper 2 siblings, 0 replies; 14+ messages in thread From: Daniel Kiper @ 2021-04-08 16:48 UTC (permalink / raw) To: Roman Shaposhnik Cc: grub-devel, Roger Pau Monné, Jan Beulich, Andrew Cooper, Xen-devel 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 ^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: multiboot2 and module2 boot issues via GRUB2 2021-03-30 18:28 multiboot2 and module2 boot issues via GRUB2 Roman Shaposhnik 2021-03-30 19:08 ` Andrew Cooper @ 2021-03-30 19:35 ` Elliott Mitchell 1 sibling, 0 replies; 14+ messages in thread From: Elliott Mitchell @ 2021-03-30 19:35 UTC (permalink / raw) To: Roman Shaposhnik; +Cc: Xen-devel 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 ^ permalink raw reply [flat|nested] 14+ messages in thread
end of thread, other threads:[~2021-04-08 18:19 UTC | newest] Thread overview: 14+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 2021-03-30 18:28 multiboot2 and module2 boot issues via GRUB2 Roman Shaposhnik 2021-03-30 19:08 ` Andrew Cooper 2021-04-01 1:06 ` Roman Shaposhnik 2021-04-01 7:31 ` Jan Beulich 2021-04-01 8:44 ` Roger Pau Monné 2021-04-01 19:43 ` Andrew Cooper 2021-04-06 8:19 ` Jan Beulich 2021-04-06 17:37 ` Roman Shaposhnik 2021-04-06 17:51 ` Andrew Cooper 2021-04-06 18:03 ` Roman Shaposhnik 2021-04-06 18:41 ` Andrew Cooper 2021-04-07 20:50 ` Glenn Washburn 2021-04-08 16:48 ` Daniel Kiper 2021-03-30 19:35 ` Elliott Mitchell
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox; as well as URLs for NNTP newsgroup(s).