RHEL Engineering is moving the tracking of its product development work on RHEL 6 through RHEL 9 to Red Hat Jira (issues.redhat.com). If you're a Red Hat customer, please continue to file support cases via the Red Hat customer portal. If you're not, please head to the "RHEL project" in Red Hat Jira and file new tickets here. Individual Bugzilla bugs in the statuses "NEW", "ASSIGNED", and "POST" are being migrated throughout September 2023. Bugs of Red Hat partners with an assigned Engineering Partner Manager (EPM) are migrated in late September as per pre-agreed dates. Bugs against components "kernel", "kernel-rt", and "kpatch" are only migrated if still in "NEW" or "ASSIGNED". If you cannot log in to RH Jira, please consult article #7032570. That failing, please send an e-mail to the RH Jira admins at rh-issues@redhat.com to troubleshoot your issue as a user management inquiry. The email creates a ServiceNow ticket with Red Hat. Individual Bugzilla bugs that are migrated will be moved to status "CLOSED", resolution "MIGRATED", and set with "MigratedToJIRA" in "Keywords". The link to the successor Jira issue will be found under "Links", have a little "two-footprint" icon next to it, and direct you to the "RHEL project" in Red Hat Jira (issue links are of type "https://issues.redhat.com/browse/RHEL-XXXX", where "X" is a digit). This same link will be available in a blue banner at the top of the page informing you that that bug has been migrated.

Description of problem:
According to the Matthew Garrett proposed update to the BLS standard [1] which is IMHO the standard for the RHEL / Fedora BLS implementation:
...
- multiple initrd entries are allowed, and will be processed in order
...

We used this standard when implementing the BLS support in Tuned, but it seems zipl doesn't support multiple initrds (bug 1576435 comment 23).

This is bad, because we need to add dirty workarounds for zipl even if we comply with the standard.

I am not sure about the s390x, but usually the support of multiple initrds consists of just concatenation of the cpio archive in the memory, which is trivial operation.

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

Version-Release number of selected component (if applicable):
s390utils-base-2.6.0-10.el8.s390x

How reproducible:
Always

Steps to Reproduce:
1. add multiple initrds like 'initrd initrd1.img initrd2.img' to the /boot/loader/entries/*.conf
2. reboot

Actual results:
It's not supported by zipl

Expected results:
It's supported by zipl

Additional info:
Currently we need the multiple initrds functionality for the x86_64, thus even if not correct approach it would be enough for us, if it just ignores it on s390x. But the right approach is to correctly support it.

Could you, please, open an upstream request for this feature at https://github.com/ibm-s390-tools/s390-tools ?

Filled https://github.com/ibm-s390-tools/s390-tools/issues/49

The design of zipl doesn't allow multiple ramdisks, see upstream ticket for the details.

Another thing that zipl doesn't support is environment variables that are supported by other bootloaders like GRUB and Petitboot. So I think that it's also incorrect to add these to the BLS snippets in s390x machines.

I've proposed the following pull-request to tuned that just makes the 92-tuned.install kernel-install plugin to exit if the machine architecture is s390x:

https://github.com/redhat-performance/tuned/pull/235