Bug 1114464

Summary: [NetApp 7.0 Bug] Anaconda doesn’t add bootdev argument in kernel cmd line to set IP address for iSCSI SANboot OS install
Product: Red Hat Enterprise Linux 7 Reporter: gowrav <gowrav.mahadevaiah>
Component: anacondaAssignee: Radek Vykydal <rvykydal>
Status: CLOSED DUPLICATE QA Contact: Release Test Team <release-test-team-automation>
Severity: urgent Docs Contact:
Priority: unspecified    
Version: 7.0CC: coughlan, ctatman, harald, rvykydal, salmy, xdl-redhat-bugzilla
Target Milestone: rc   
Target Release: ---   
Hardware: All   
OS: Linux   
Whiteboard:
Fixed In Version: Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2014-07-01 10:55:23 UTC Type: Bug
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:
Embargoed:
Attachments:
Description Flags
RHEL7 iSCSI Sanboot IP assign fail
none
RHEL7 iSCSI Sanboot bootup fail
none
Anaconda Logs
none
dmesg after OS installation none

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.