Created attachment 1860726 [details] rdsosreport.txt generated by the installer with the ip=ibft rd.iscsi.ibft=1 rd.iscsi.mp=1 kernel arguments. Description of problem: Booting the installer over PXE from an iSCSI target causes the system to drop to a dracut emergency shell. The installation can only be continued if the user manually brings up the network and runs iscsiadm --mode fw -l && anaconda-diskroot. Version-Release number of selected component (if applicable): How reproducible: Always. Steps to Reproduce: 1. Configure an iSCSI target to provide the raw install media (I used CentOS-Stream-8-x86_64-20210819-dvd1.iso) as a read only iSCSI CD/DVD target. 2. Point a iSCSI compatible PXE client (I used iPXE's sanboot command) to the configured iSCSI target. 3. When the boot screen appears select the "test this media & install centos 8 stream" option and add ip=ibft as per: https://access.redhat.com/documentation/en-us/red_hat_enterprise_linux/8/html/performing_a_standard_rhel_installation/iscsi-disks-in-installation-program_installing-rhel Actual results: The kernel loads and detects the iBFT block in memory but fails to bring back up the LUN it describes. (According to the log, NetworkManager seems to be stuck in a restart loop.) iscsiadm --mode fw will show the config provided by the PXE client used to load the kernel, but will not have connected yet. Expected results: The network comes up, iscsiadm brings up the LUN and anaconda-diskroot finds the install media. Additional info: Unfortunately, adding rd.iscsi.ibft=1 and rd.iscsi.mp=1 (https://man7.org/linux/man-pages/man7/dracut.cmdline.7.html) to the kernel cmdline still doesn't get the iSCSI LUN connected automatically. To get the installer to continue in either case once the network is up the user can manually run in the dracut console: iscsiadm --mode fw -l # To bring up the LUN. blkid # To find the block device for said LUN. anaconda-diskroot </dev/path/to/iSCSI/block/device> # To mount the install media. exit # To return control to dracut and continue the installation.
Created attachment 1860727 [details] /tmp/syslog after running the commands to get the installer to continue.
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.