Bug 1194241

Summary: zFCP LUN with non-system mount point is not brought online during boot
Product: Red Hat Enterprise Linux 7 Reporter: Jan Stodola <jstodola>
Component: python-blivetAssignee: Samantha N. Bueno <sbueno>
Status: CLOSED ERRATA QA Contact: Release Test Team <release-test-team-automation>
Severity: high Docs Contact:
Priority: high    
Version: 7.1CC: sbueno
Target Milestone: rcKeywords: Triaged
Target Release: ---   
Hardware: s390x   
OS: Linux   
Whiteboard:
Fixed In Version: python-blivet-0.61.15.5-1 Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2015-11-19 08:47:29 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:
Bug Depends On:    
Bug Blocks: 1186677, 1205794    
Attachments:
Description Flags
anaconda.program.log
none
anaconda.storage.log
none
zipl.conf none

Description Jan Stodola 2015-02-19 11:49:34 UTC 
Description of problem:
I've created following partitions during installation, having /mnt/data mount point as the only partition on a FCP LUN (/dev/sda):

[root@rtt7 ~]# lsblk 
NAME     MAJ:MIN RM  SIZE RO TYPE MOUNTPOINT
sda        8:0    0    8G  0 disk 
└─sda1     8:1    0    3G  0 part /mnt/data
dasda     94:0    0  2.3G  0 disk 
└─dasda1  94:1    0  2.1G  0 part /
dasdb     94:4    0  2.3G  0 disk 
└─dasdb1  94:5    0  500M  0 part /boot
dasdc     94:8    0  2.3G  0 disk 
└─dasdc1  94:9    0  600M  0 part [SWAP]
[root@rtt7 ~]#

The FCP disk has device number a007, WWPN 0x500507630500c73d and LUN 0x4020400700000000

After reboot, system fails to boot, because the FCP device backing /mnt/data is not freed from the cio_ignore list and brought online:

[root@rtt7 ~]# cat /proc/cio_ignore
0.0.0000-0.0.0008  
0.0.000a-0.0.09ff  
0.0.0a03-0.0.3526  
0.0.3528-0.0.3626  
0.0.3628-0.0.3726  
0.0.3728-0.0.ffff  
0.1.0000-0.1.ffff  
0.2.0000-0.2.ffff  
0.3.0000-0.3.ffff  
[root@rtt7 ~]# 

Version-Release number of selected component (if applicable):
anaconda-19.31.122-1.el7
python-blivet-0.61.0.25-1.el7

How reproducible:
always

Steps to Reproduce:
1. start installation with DASD/FCP devices defined on the kernel command line
2. create partitioning where data mount point (/mnt/data) is the only mount point on a FCP LUN
3. reboot to installed system

Actual results:
system fails to boot, /mnt/data cannot be mounted

Expected results:
system boots without errors

Additional info:
* /etc/zfcp.conf was not created during the installation

Workaround:
1) enter root password to enter emergency mode
2) add a record to /etc/zfcp.conf for every FCP LUN with data (non-system) mount point:
echo "0.0.a007 0x500507630500c73d 0x4020400700000000" >> /etc/zfcp.conf
3) reboot
Comment 1 Jan Stodola 2015-02-19 11:51:02 UTC 
Created attachment 993578 [details]
anaconda.log
Comment 2 Jan Stodola 2015-02-19 11:51:06 UTC 
Created attachment 993579 [details]
anaconda.packaging.log
Comment 3 Jan Stodola 2015-02-19 11:51:08 UTC 
Created attachment 993580 [details]
anaconda.program.log
Comment 4 Jan Stodola 2015-02-19 11:51:22 UTC 
Created attachment 993581 [details]
anaconda.storage.log
Comment 5 Jan Stodola 2015-02-19 11:51:24 UTC 
Created attachment 993582 [details]
syslog
Comment 6 Jan Stodola 2015-02-19 11:51:40 UTC 
Created attachment 993583 [details]
zipl.conf
Comment 9 Jan Stodola 2015-08-27 14:49:26 UTC 
Retested on compose RHEL-7.2-20150820.0 with python-blivet-0.61.15.23-1.el7. This issue is fixed and system booted with the following partitioning layout:

[root@rtt7 ~]# lsblk 
NAME     MAJ:MIN RM  SIZE RO TYPE MOUNTPOINT
sda        8:0    0    8G  0 disk 
└─sda1     8:1    0    8G  0 part /mnt/data
dasda     94:0    0  2.3G  0 disk 
└─dasda1  94:1    0  2.3G  0 part /
dasdb     94:4    0  2.3G  0 disk 
└─dasdb1  94:5    0  500M  0 part /boot
dasdc     94:8    0  2.3G  0 disk 
└─dasdc1  94:9    0  2.3G  0 part [SWAP]
[root@rtt7 ~]# cat /etc/zfcp.conf 
0.0.a007 0x500507630500c73d 0x4020400700000000
[root@rtt7 ~]#

Thanks for fixing it, sbueno.
Moving to VERIFIED.
Comment 10 errata-xmlrpc 2015-11-19 08:47:29 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://rhn.redhat.com/errata/RHBA-2015-2232.html