RHEL Engineering is moving the tracking of its product development work on RHEL 6 through RHEL 9 to Red Hat Jira (issues.redhat.com). If you're a Red Hat customer, please continue to file support cases via the Red Hat customer portal. If you're not, please head to the "RHEL project" in Red Hat Jira and file new tickets here. Individual Bugzilla bugs in the statuses "NEW", "ASSIGNED", and "POST" are being migrated throughout September 2023. Bugs of Red Hat partners with an assigned Engineering Partner Manager (EPM) are migrated in late September as per pre-agreed dates. Bugs against components "kernel", "kernel-rt", and "kpatch" are only migrated if still in "NEW" or "ASSIGNED". If you cannot log in to RH Jira, please consult article #7032570. That failing, please send an e-mail to the RH Jira admins at rh-issues@redhat.com to troubleshoot your issue as a user management inquiry. The email creates a ServiceNow ticket with Red Hat. Individual Bugzilla bugs that are migrated will be moved to status "CLOSED", resolution "MIGRATED", and set with "MigratedToJIRA" in "Keywords". The link to the successor Jira issue will be found under "Links", have a little "two-footprint" icon next to it, and direct you to the "RHEL project" in Red Hat Jira (issue links are of type "https://issues.redhat.com/browse/RHEL-XXXX", where "X" is a digit). This same link will be available in a blue banner at the top of the page informing you that that bug has been migrated.
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"
Keywords:
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:
Depends On:
Blocks: 1557360
TreeView+ depends on / blocked
 
Reported: 2018-03-30 04:44 UTC by Masahiro Matsuya
Modified: 2022-03-13 14:49 UTC (History)
9 users (show)

Fixed In Version: anaconda-21.48.22.137-1
Doc Type: Enhancement
Doc Text:
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)
Environment:
Last Closed: 2018-10-30 07:53:20 UTC
Target Upstream Version:
Embargoed:

Attachments (Terms of Use)


Links
System ID Private Priority Status Summary Last Updated
Red Hat Bugzilla 1561734 1 None None None 2021-01-20 06:05:38 UTC
Red Hat Product Errata RHBA-2018:3035 0 None None None 2018-10-30 07:53:59 UTC

Internal Links: 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.