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.
rhel-9 clone: bug 2221932
upstream PR for Anaconda: https://github.com/rhinstaller/anaconda/pull/4933 and Blivet: https://github.com/storaged-project/blivet/pull/1146 updates image for RHEL 8.8: https://vtrefny.fedorapeople.org/img/rhbz2084043_8-8.img
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.