zipl: please add support for multiple initrds

[yarda]

In Fedora / RHEL we use modified BLS [1] which requires multiple initrds support. It's generally useful feature. We utilize multiple initrds in e.g. Tuned SW.

I am not sure about s390x, but usually it requires just concatenation of the initrd images in the memory which is trivial operation, so hopefully this is not hard to implement.

There is original downstream bugzilla [2].

[1] https://fedoraproject.org/wiki/Changes/BootLoaderSpecByDefault#Differences_from_BootLoaderSpec
[2] https://bugzilla.redhat.com/show_bug.cgi?id=1657858

[sharkcz]

adding our BLS expert @martinezjavier

[yarda]

From [1]:
...

• multiple initrd entries are allowed, and will be processed in order

...

[1] https://fedoraproject.org/wiki/Changes/BootLoaderSpecByDefault#Differences_from_BootLoaderSpec

[martinezjavier]

@yarda @sharkcz note that this is not only a limitation of the BLS support but zipl itself. As far as I know there isn't support for multiple initrds images in neither the zipl.conf file nor the zipl command line tool.

So I would also like the opinion of the zipl folks to on how to properly support this: @hoeppnerj, @oberpar, @stefan-haberland

[yarda]

@martinezjavier thanks for info. Maybe for the start you could just ignore successive initrd images in the BLS entries conf, e.g. with some error/warning message. I think it's better than error. I am going to add dirty workaround to our Tuned SW for zipl until properly resolved in zipl.

[sharkcz]

@martinezjavier right, that's why I asked @yarda to bring it here.

[oberpar]

I don't think this proposed change fits into zipl's initrd handling:.

zipl treats each file specified on the command line or in the zipl.conf file as a separate "load component", with a distinct load address and handling during boot. Specifying multiple initrd files (as separate command line/config file entities) that are then concatenated into one load component does not fit this design.

Specifying multiple initrd entries that are handled as separate components by zipl would be acceptable, but the load address and size of the initrd component is stored into the loaded kernel image during boot. This can be considered an ABI between boot loader and kernel image on s390. As far as I can tell there's no room for storing address and size of multiple initrds, nor code that would handle these additional initrds.

The simplest solution from my point of view would be to generate a concatenated initrd component before invoking zipl.

[martinezjavier]

Based on the comment from @oberpar we should probably close this issue, since the proposed change doesn't fit into zipl design and instead the initrd concatenation has to be done by another component that invokes zipl.

[hoeppnerj]

Closing as per previous comments.