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:
On s390x, there is no alternative to fw_cfg which is used to inject user data.
https://github.com/coreos/ignition/issues/825

On talking about this to Christian Borntraeger, this is what he had to say:

"As of today there is no fw_cfg on s390. In fact this is very architecture specific and it would be better if ignition would use something else (like cloud-init a disk).The driver uses ACPI or devicetree, mmio or port I/O. None of this exists on s390x.We would need to refactor that driver (as if conflicts with CONFIG_NO_IOPORT_MAP) and we would need to build a new transport - with changes in the guest and QEMU.

Maybe we could use the sclp-sd driver and let QEMU provide the data.
https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/drivers/s390/char/sclp_sd.c?id=66aec647216f129b8560dba738303a8486481c53
But this would take a time."

We do have a config disk option but the CoreOS team is not highly favorable with that option because there might be race conditions with the disk showing up.

I am filing this BZ as a tracker so that we can have a qemu native solution for s390x.

for the record - https://github.com/coreos/ignition/issues/656#issuecomment-441898962 and https://github.com/coreos/coreos-assembler/issues/194#issuecomment-441720838 are original tickets dealing with qemu_fw_cfg

Yesterday, we've discussed this again with the engineers from IBM, and it really seems like the fw_cfg interface is very architecture specific. So even if it would maybe be possible to implement something similar on s390x, the usage of the device might still differ quite a bit from the implementations on the other architectures.

So Prashanth, two questions:

1) Do you have a good workaround / alternate solution in place already which is good enough for your usecase, too?

2) If not, and we really might have to implement a fw_cfg interface on s390x, would that still be fine for you if the usage of the interface differs quite a bit from the other architectures?

Hi Thomas,

To answer your question, 

1 - yes we have a sufficient workaround we use for now

2- it is fine if the interface differs quite a bit from fw_cfg as long as it is not too much of a deviation 

Thanks

After evaluating this issue, there are no plans to address it further or fix it in an upcoming release.  Therefore, it is being closed.  If plans change such that this issue will be fixed in an upcoming release, then the bug can be reopened.