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 1114464 - [NetApp 7.0 Bug] Anaconda doesn’t add bootdev argument in kernel cmd line to set IP address for iSCSI SANboot OS install
Summary: [NetApp 7.0 Bug] Anaconda doesn’t add bootdev argument in kernel cmd line to ...
Keywords:
Status: CLOSED DUPLICATE of bug 1103571
Alias: None
Product: Red Hat Enterprise Linux 7
Classification: Red Hat
Component: anaconda
Version: 7.0
Hardware: All
OS: Linux
unspecified
urgent
Target Milestone: rc
: ---
Assignee: Radek Vykydal
QA Contact: Release Test Team
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2014-06-30 06:58 UTC by gowrav
Modified: 2015-02-11 14:23 UTC (History)
6 users (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
Environment:
Last Closed: 2014-07-01 10:55:23 UTC
Target Upstream Version:
Embargoed:


Attachments (Terms of Use)
RHEL7 iSCSI Sanboot IP assign fail (91.00 KB, image/png)
2014-06-30 06:58 UTC, gowrav
no flags Details
RHEL7 iSCSI Sanboot bootup fail (70.99 KB, image/png)
2014-06-30 07:02 UTC, gowrav
no flags Details
Anaconda Logs (182.47 KB, application/x-gzip)
2014-06-30 07:04 UTC, gowrav
no flags Details
dmesg after OS installation (202.78 KB, text/plain)
2014-06-30 07:05 UTC, gowrav
no flags Details

Description gowrav 2014-06-30 06:58:48 UTC
Created attachment 913264 [details]
RHEL7 iSCSI Sanboot IP assign fail

Description of problem:
Anaconda does not add the required bootdev argument in kernel command line to set IPv4 address during iSCSI SANboot OS installation. So at boot time IP address does not get assigned to the any of the Ethernet ports that were configured at start of OS installation (Refer attached screen shot - RHEL7_iSCSI_Sanboot_IP_fail). Since IP addresses are not assigned, iSCSI sessions to the target is not established. Hence the root LUN is not discovered at boot time and OS boot fails (Refer attached screen shot - RHEL7_iSCSI_Sanboot_bootup).

Below is the snippet from /etc/grub2.cfg file that shows IPv4 address not being added to kernel cmd line. Though 2 Ethernet ports (ens1f0, ens1f1) are defined along with their respective MAC address, the “ip=” parameter does not have IPv4 address and netmask values.

linux16 /vmlinuz-3.10.0-123.el7.x86_64 root=UUID=2bc9e0c8-31b7-4c74-b755-ba8f645ce741 ro ifname=ens1f0:00:00:c9:b0:47:98 vconsole.keymap=us ip=::::IBMx3550-210-127:ens1f0:none ip=::::IBMx3550-210-127:ens1f1:none ifname=ens1f1:00:00:c9:b0:47:9a netroot=iscsi:@10.10.10.10::3260::iqn.1992-08.com.netapp:sn.5d35f5e7ed9711e3ba53123478563412:vs.10 netroot=iscsi:@11.11.11.11::3260::iqn.1992-08.com.netapp:sn.5d35f5e7ed9711e3ba53123478563412:vs.10 crashkernel=auto  rd.lvm.lv=rhel_210-127/root rd.lvm.lv=rhel_210-127/swap netroot=iscsi:@11.11.11.10::3260::iqn.1992-08.com.netapp:sn.5d35f5e7ed9711e3ba53123478563412:vs.10 iscsi_initiator=iqn.1994-05.com.redhat:127 netroot=iscsi:@10.10.10.11::3260::iqn.1992-08.com.netapp:sn.5d35f5e7ed9711e3ba53123478563412:vs.10 vconsole.font=latarcyrheb-sun16 rhgb quiet LANG=en_US.UTF-8
During the first boot after OS installation, user has to edit the kernel cmd line to add the IPv4 address and netmask values in order to discovery iSCSI sessions, find root LUN and to boot further. Else the OS boot will fail.
Modified cmd line:
linux16 /vmlinuz-3.10.0-123.el7.x86_64 root=UUID=2bc9e0c8-31b7-4c74-b755-ba8f645ce741 ro ifname=ens1f0:00:00:c9:b0:47:98 vconsole.keymap=us ip=10.10.10.127:::255.255.255.0:IBMx3550-210-127:ens1f0:none ip=11.11.11.127:::255.255.255.0:IBMx3550-210-127:ens1f1:none ifname=ens1f1:00:00:c9:b0:47:9a netroot=iscsi:@10.10.10.10::3260::iqn.1992-08.com.netapp:sn.5d35f5e7ed9711e3ba53123478563412:vs.10 netroot=iscsi:@11.11.11.11::3260::iqn.1992-08.com.netapp:sn.5d35f5e7ed9711e3ba53123478563412:vs.10 crashkernel=auto  rd.lvm.lv=rhel_210-127/root rd.lvm.lv=rhel_210-127/swap netroot=iscsi:@11.11.11.10::3260::iqn.1992-08.com.netapp:sn.5d35f5e7ed9711e3ba53123478563412:vs.10 iscsi_initiator=iqn.1994-05.com.redhat:127 netroot=iscsi:@10.10.10.11::3260::iqn.1992-08.com.netapp:sn.5d35f5e7ed9711e3ba53123478563412:vs.10 vconsole.font=latarcyrheb-sun16 rhgb quiet LANG=en_US.UTF-8
This is a regression from RHEL 6.x behavior, where Anaconda used to add the IPv4 address to the respective Ethernet ports in kernel cmd line.


Version-Release number of selected component (if applicable):
OS: RHEL 7.0
Kernel: 3.10.0-123.el7.x86_64
iSCSI: iscsi-initiator-utils-6.2.0.873-21.el7.x86_64
Anaconda: 19.31.79-1

How reproducible:


Steps to Reproduce:
1. Map a SANBoot LUN to RHEL 7.0 iSCSI host
2. Start RHEL 7.0 OS installation on the iSCSI host
3. In the first anaconda OS installation screen, set the IPv4 address on the interface that are intended for establishing iSCSI sessions. In our testbed it was ens1f0, ens1f1.
4. Go to Installation menu, to discovery and login IPv4 iSCSI sessions. Once iSCSI sessions are logged in, the SANBoot LUN is discovered.
5. Select both local disk and SANBoot LUN for creating partitions.
6. In Partition menu, create “/boot” partition on local disk. On SANBoot LUN create “root” (/) and “swap” partitions on top of LVM.
7. Begin OS installation and reboot the host after installation completes.
8. Upon first reboot, IP address is not assigned to any of the Ethernet ports and hence iSCSI sessions are not established (Refer attached screen shot – RHEL7_iSCSI_Sanboot_IP_fail).
9. Since iSCSI login fails, SANBoot LUN is also not discovered and hence OS boot fails (Refer attached screen shot – RHEL7_iSCSI_Sanboot_bootup).


Actual results:
Anaconda does not add required bootdev arguments to kernel cmd line to set IP address to Ethernet ports during iSCSI SANBoot installation.

Expected results:
Anaconda should add necessary bootdev arguments s to kernel cmd line to set IP address on all Ethernet ports that were configured at start of OS installation.

Additional info:

Comment 1 gowrav 2014-06-30 07:02:30 UTC
Created attachment 913267 [details]
RHEL7 iSCSI Sanboot bootup fail

Comment 2 gowrav 2014-06-30 07:04:21 UTC
Created attachment 913269 [details]
Anaconda Logs

Comment 3 gowrav 2014-06-30 07:05:23 UTC
Created attachment 913270 [details]
dmesg after OS installation

Comment 5 Radek Vykydal 2014-07-01 10:55:23 UTC

*** This bug has been marked as a duplicate of bug 1103571 ***

Comment 6 Radek Vykydal 2014-07-01 10:58:24 UTC
The anaconda.ifcfg.log from comment #2 logs is corrupted, but I suppose we'd see GATEWAY0 and similar options in it, which would confirm this is indeed a duplicate of bug 1103571.

Comment 7 gowrav 2014-07-01 17:54:43 UTC
Can i get access to bug 1103571 to understand the status and follow the updates?

Comment 8 Radek Vykydal 2014-07-02 10:54:24 UTC
(In reply to gowrav from comment #7)
> Can i get access to bug 1103571 to understand the status and follow the
> updates?

I've asked reporters of the BZ if they are OK with the access. Basically, the issue will be resolved by fixing NetworkManager bug 1105770.

Comment 9 gowrav 2015-02-11 14:23:46 UTC
Fix was verified with RHEL 7.1 build.


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