+++ This bug was initially created as a clone of Bug #2084043 +++

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