Re: multiboot2 and module2 boot issues via GRUB2

[Andrew Cooper <andrew.cooper3@xxxxxxxxxx>]

On 06/04/2021 19:03, Roman Shaposhnik wrote:

On Tue, Apr 6, 2021 at 10:51 AM Andrew Cooper <andrew.cooper3@xxxxxxxxxx> 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.

    ?
    
    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