Hide Forgot
Description of problem: From RHEL7.2, locating /boot partition on iscsi which is not configured with iBFT is not allowed. This was a fix in https://bugzilla.redhat.com/show_bug.cgi?id=1164195. Also, the installation guide was changed. I thought that the following was assumed for the decision. - boot loader can get iscsi information from iBFT configuration only after installation to find kernel and initrd.img. But, a customer has a different scenario. - He is using iPXE for booting a diskless server. - iPXE can get iscsi information from IPXE configuration itself, not from iBFT. And, it can boot the system without a help of iBFT. So, his expectation was to locate /boot partition on iscsi device which is not configured with iBFT. But, it's not possible currently, though it was possible with RHEL7.1. In this case, it can be a regression from a viewpoint of this customer. For installation, the customer is using DVD in a removable USB DVD drive. And, he specifies his kickstart file in the first prompt as boot parameter. This server doesn't have any local disks. And, he cannot locate /boot partition on iscsi device. NOTE: this customer's server doesn't have iBFT feature in BIOS. So, it's not possible to configure it with iBFT. I think the current default behavior is ok. But, can we add a new boot parameter to allow to create /boot partition on iscsi device which is not configured with iBFT? Version-Release number of selected component (if applicable): Red Hat Enterprise Linux 7 How reproducible: Always Steps to Reproduce: 1. configure a iscsi target for testing. 2. prepare diskless server 3. start RHEL7.4 installation. 4. login to the iscsi target and make auto partition. Actual results: It fails with "stage1 device cannot be on an iSCSI disk", and cannot proceed the installation. Expected results: A way to avoid the error should be available for a workaround. Additional info: The similar request was rejected in https://bugzilla.redhat.com/show_bug.cgi?id=1294571. I can see the following in C#7. > We just make the assumption that when placing stage 1 on an iSCSI device, > user wants to boot from that device, so the device (iSCSI target) for booting > is configured in iBFT table. This assumption is not applied to this customer's scenario, because the device (iSCSI target) for booting can be configured in iPXE configuration as well.
I think adding a boot option is a good way to go. Also we should improve the UI feedback to be more informative, from: "failed to find a suitable stage1 device" to something like: "Failed to find a suitable stage1 device: Bootloader stage 1 device cannot be on iSCSI disk which is not configured in iBFT." I've prepared an updates image for RHEL 7.5 with a patch adding inst.nonibftiscsiboot option that should do the thing. https://rvykydal.fedorapeople.org/updates.nonibftiscsiboot.img (https://github.com/rvykydal/anaconda/commits/rhel7-branch-non-ibft-boot)
https://github.com/rhinstaller/anaconda/pull/1437
In addition to the inst.nonibftiscsiboot option the messaging in UI has been improved, see the second comment in the PR https://github.com/rhinstaller/anaconda/pull/1437
With the updated details from comment #9 I re-tested with a kickstart file that contains: iscsiname iqn.2015-04.com.client:target1 iscsi --ipaddr 10.34.112.115 --port 3260 --target iqn.2015-04.com.example:target1 zerombr bootloader --location=mbr clearpart --all --initlabel autopart --type=lvm I used a VM without any kind of local storage, provisioning via virt-manager: Without inst.nonibftiscsiboot option the error message is: Failed to find a suitable stage1 device: Boot loader stage1 device cannot be on an iSCSI disk which is not configured in iBFT. With the inst.nonibftiscsiboot I was able to proceed with the installation, the disk device (/dev/sda) was partitioned with LVM and a /boot partition. Then I was able to boot the system by typing the following in the iPXE prompt: > dhcp net0 > sanboot iscsi:10.34.112.115:::0:iqn.2015-04.com.example:target1
Thanks, Radek. I've made some minor grammatical edits. Thanks again.
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, 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-2018:3035