Note: This bug is displayed in read-only format because
the product is no longer active in Red Hat Bugzilla.
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 RHVH - which is an image based system like atomic - the initiator IQN s the same on all hosts, because the IQN is generated during the the build of the image.
To have unique IQNs across different hosts, the IQN needs to be generated at the first boot - or at least at runtime - and not during build time of the image (thus not in rpm %post).
Version-Release number of selected component (if applicable):
iscsi-initiator-utils-6.2.0.873-25.gitc9d830b.fc22.x86_64
How reproducible:
Always
Steps to Reproduce:
1. Build an image which includes iscsi-initiator-utils-6.2.0.873-25.gitc9d830b.fc22.x86_64
2.
3.
Actual results:
After 1 the image contains a initiator IQN in /etc/iscsi/initiatorname.iscsi
Expected results:
After 1 the image a service to generate a initiator IQN in /etc/iscsi/initiatorname.iscsi
Additional info:
There's a few things I'd want to check before jumping on firstboot vs RPM install scripts. Like what happens if you install the RPM after the first boot? And is anaconda relying on the RPM install to generate an IQN for iSCSI boot installs.
Right - What I rather meant with the "firstboot" is: On the first start of the service, if the file is non-existent, then generate a new file.
The service should actually have the condition to only run if the file does not exists.
That should cover two cases:
1. Generates a random name on the first start (of the service) after the rpm got installed
2. Would not touch a an empty name file (which IIUIC is needed to cove rthe hardware initiator case).
To keep backwards compatibility the rpm %post could still be generating the file, but a service could be added to regenerate the file if it get's deleted.
We would then delete the name file in our builds, to get them generated on the first boot.
On RHEL nothing would happen, because the name file is still getting installed during rpm %post.
Not really sure about RHEL, but I don't think it was fixed. For RHVH, we're handling this by ourselves - we delte the file in build time, and generate it on first boot with our service
stale bug and lacking info to resolve in z-stream. removing z-request
Comment 15RHEL Program Management
2021-01-15 07:28:30 UTC
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.