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:
I have a customer that is trying to install a system having iBFT firmware support and initiator set in the firmware.
Upon booting on the DVD for installation in GUI mode, the iSCSI panel prefills the initiator name with the initiator found in the firmware and the field is automatically grayed out, which is somehow expected.
However discovery fails because /etc/iscsi/initiator-name was not updated with the iBFT initiator, it's still the one stored on the DVD.
This ends up not finding any target and not being able to fix this, unless the customer switches to a text console, changes /etc/iscsi/initiator-name content and restarts iscsid.service unit.
Unfortunately I don't have the hardware to reproduce.
So far, by stracing much of the components on my lab system, I could find that when setting the initiator field manually (something the customer cannot do since it's grayed out), the following sequence happens:
1. DBus message "SetInitiator" is sent
2. udisksd (udisks2.service unit) spawns a child that changes /etc/iscsi/initiator-name
3. the child connects to the target IP, causing iscsid.service activation to take place
It's unclear to me who retrieved the iBFT firmware value in the first place and populated it in the initiator field.
For sure once the field is populated a "SetInitiator" must be issued since the static file isn't accurate anymore.
Version-Release number of selected component (if applicable):
Anaconda RHEL8.5.0 and RHEL8.6.0
How reproducible:
Always on customer system
Steps to Reproduce:
1. Boot the installation while having iBFT configured
2. Open iSCSI panel and configure Target IP
3. Click on discovery
Actual Result:
iscsid used the DVD initiator instead of iBFT one
Radek, can you take a look at this? In this situation Blivet never writes the initiator name to /etc/iscsi/initiator-name and it looks intentional -- only time we write the file is when Anaconda uses the API to set the initiator name, with iBFT we read it using UDisks GetFirmwareInitiatorName a basically ignore the file and it looks intentional not a result of a recent change. I have no problem with updating the file after we get the initiator name, I am just not sure whether it makes sense or whether Anaconda or something else (dracut?) should update the file.
Checked that anaconda-33.16.9.4-1.el8 and python-blivet-3.6.0-7.el8 are in nightly compose RHEL-8.9.0-20230812.18.
Executed automated iSCSI tests using compose RHEL-8.9.0-20230812.18 and no regressions have been found.
Moving to VERIFIED.
Since the problem described in this bug report should be
resolved in a recent advisory, it has been closed with a
resolution of ERRATA.
For information on the advisory (python-blivet bug fix and enhancement update), and where to find the updated
files, follow the link below.
If the solution does not work for you, open a new bug report.
https://access.redhat.com/errata/RHBA-2023:7004