Bug 1562301 - diskless installation fails with "stage1 device cannot be on an iSCSI disk"
Summary: diskless installation fails with "stage1 device cannot be on an iSCSI disk"
Status: CLOSED ERRATA
Alias: None
Product: Red Hat Enterprise Linux 7
Classification: Red Hat
Component: anaconda
Version: 7.4
Hardware: All
OS: Linux
medium
medium
Target Milestone: rc
: ---
Assignee: Radek Vykydal
QA Contact: Release Test Team
Sharon Moroney
URL:
Whiteboard:
Keywords:
Depends On:
Blocks: 1557360
TreeView+ depends on / blocked
 
Reported: 2018-03-30 04:44 UTC by Masahiro Matsuya
Modified: 2018-11-26 11:08 UTC (History)
9 users (show)

(edit)
Booting from an iSCSI device that is not configured using iBFT is now supported

This update provides a new installer boot option "inst.nonibftiscsiboot" that supports the installation of boot loader on an iSCSI device that has not been configured in the iSCSI Boot Firmware Table (iBFT).

This update helps when the iBFT is not used for booting the installed system from an iSCSI device, for example, an iPXE boot from SAN features is used instead. The new installer boot option allows you to install the boot loader on an iSCSI device that is not automatically added as part of the iBFT configuration but is manually added using the "iscsi" Kickstart command or the installer GUI.
Clone Of:
: 1572600 (view as bug list)
(edit)
Last Closed: 2018-10-30 07:53:20 UTC


Attachments (Terms of Use)


External Trackers
Tracker ID Priority Status Summary Last Updated
Red Hat Product Errata RHBA-2018:3035 None None None 2018-10-30 07:53 UTC
Red Hat Bugzilla 1561734 None None None 2019-07-15 15:11 UTC

Internal Trackers: 1561734

Description Masahiro Matsuya 2018-03-30 04:44:05 UTC
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.

Comment 1 Radek Vykydal 2018-04-13 15:59:15 UTC
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)

Comment 3 Radek Vykydal 2018-04-18 11:22:04 UTC
https://github.com/rhinstaller/anaconda/pull/1437

Comment 4 Radek Vykydal 2018-04-27 13:14:02 UTC
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

Comment 10 Alexander Todorov 2018-08-02 11:30:47 UTC
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

Comment 14 Sharon Moroney 2018-08-09 12:42:19 UTC
Thanks, Radek. I've made some minor grammatical edits. Thanks again.

Comment 16 errata-xmlrpc 2018-10-30 07:53:20 UTC
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


Note You need to log in before you can comment on or make changes to this bug.