Bug 696827

Summary: Anaconda ignores --ondisk/--ondrive argument?
Product: Red Hat Enterprise Linux 5 Reporter: David Barr <dafydd>
Component: anacondaAssignee: Anaconda Maintenance Team <anaconda-maint-list>
Status: CLOSED CURRENTRELEASE QA Contact: Release Test Team <release-test-team>
Severity: high Docs Contact:
Priority: unspecified    
Version: 5.4   
Target Milestone: rc   
Target Release: ---   
Hardware: Unspecified   
OS: Unspecified   
Whiteboard:
Fixed In Version: Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2013-03-08 19:16:05 UTC Type: ---
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:
Attachments:
Description Flags
Log file from failed attempt.
none
Log file from successful attempt. none

Description David Barr 2011-04-14 23:31:38 UTC 
+++ Description of problem:
When kickstarting in a multipath environment, with three multipath LUNS, Anaconda persists in trying to use an incorrect LUN for its root disk.

+++ Version-Release number of selected component (if applicable):
anaconda-11.1.2.195-1.x86_64

+++ How reproducible:
Every time.

+++ Steps to Reproduce:
1. Set up hardware with multiple paths to a SAN. Set up at least two LUNS visible to the host.
2. Use the following kickstart script elements.
3. Watch the <ALT><CTRL><F3> console during installation.
  
+++ Actual results:
From the console:

HH:MM:SS INFO : pv is /dev/mapper/mpath1p2 in vg VolRoot, size is 34553
HH:MM:SS INFO : vg VolRoot, size is 34528, pesize is 32768
HH:MM:SS ERROR : Volume Group VolRoot using non-existent partition /dev/mapper/mpath1p2


+++ Expected results:
The PV should be using mpath0, as specified below, and installing.


+++ Additional info:
Relevant pieces of the kickstart file:

install
text
network --bootproto dhcp
url --url [REDACTED]
lang en_US
keyboard us
zerombr
clearpart --drives=mapper/mpath0
bootloader --location mbr
timezone America/Los_Angeles
auth --enablemd5 --enableshadow --enableldap
rootpw --iscrypted [REDACTED]
selinux --disabled
reboot
firewall --disabled
skipx
key --skip
ignoredisk --only-use=mapper/mpath0
repo --name=[REDACTED] --baseurl=[REDACTED]
repo --name=[REDACTED] --baseurl=[REDACTED]
part /boot --fstype=ext3 --size=256 --ondrive=mapper/mpath0
part pv.01 --size=1000 --grow --ondrive=mapper/mpath0
volgroup VolRoot pv.01
logvol / --vgname=VolRoot --name=rootfs --size=5020
logvol /tmp --vgname=VolRoot --name=tmp --size=1088
logvol /var --vgname=VolRoot --name=var --size=2048
logvol /var/log --vgname=VolRoot --name=varlog --size=512
logvol swap --vgname=VolRoot --name=swap --size=2048
logvol /u01 --vgname=VolRoot --name=u01 --size=10240 --grow

-) Note that "part pv.01" specifies using mapper/mpath0. So, why isn't anaconda/multipath/lvm/whoever paying attention to ?

-) This was attempted with both --ondisk and --ondrive, with no difference in results.

-) I don't have copy/paste access to the console, but I have run "multipath -l" and verified that mpath0 is LUN0, the root device. Mpath1 is LUN11, correctly. Mpath2 is LUN12, correctly.
Comment 1 Chris Lumens 2011-04-15 02:15:02 UTC 
Please attach /tmp/anaconda.log to this bug report.  Also, it's definitely --ondisk, not --nodevice.
Comment 2 David Barr 2011-04-15 03:59:56 UTC 
Just to check, is this the non-chrooted /tmp, or the chrooted /tmp? (Hopefully, getting networking started won't be difficult.)
Comment 3 Chris Lumens 2011-04-15 14:29:57 UTC 
Non-chrooted.
Comment 4 David Barr 2011-04-15 16:12:51 UTC 
Curiouser and curiouser...

Let's call the host on which I encountered this problem "h01." It has one logical drive to itself (LUN 0: 34GB), and two logical drives it will share with the other Oracle RAC node (LUN 11: 840GB becomes mpath1, LUN 12: 4.2TB becomes mpath2). With LUN 0 to itself and LUNs 11 & 12 shared, we get h01.anaconda.log.

Now, I ~must~ turn over h01 and h08 to the Oracle team today. So, I created two logical drives for testing (100GB each on LUNs 11 & 12) and attached them to h14 without sharing them with any other hosts.

That is currently installing just fine. :p

I'll try to squeeze out a host to try to rule out the LUN sharing. The other possible difference is the sizes of the LUNs.

Having said all that, if I'm reading the logs right, anaconda appears to still look at the devices after setting up the /dev/mapper paths.
Comment 5 David Barr 2011-04-15 16:13:41 UTC 
Created attachment 492421 [details]
Log file from failed attempt.
Comment 6 David Barr 2011-04-15 16:14:14 UTC 
Created attachment 492422 [details]
Log file from successful attempt.
Comment 7 David Barr 2011-04-15 17:21:04 UTC 
Retested h14 while sharing the two test LUNs, and that worked.

I don't have another 4TB to try crosschecking the file size possibility.
Comment 8 David Cantrell 2013-03-08 19:16:05 UTC 
CLosing per comment #7.