Hide Forgot
+++ 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.
Please attach /tmp/anaconda.log to this bug report. Also, it's definitely --ondisk, not --nodevice.
Just to check, is this the non-chrooted /tmp, or the chrooted /tmp? (Hopefully, getting networking started won't be difficult.)
Non-chrooted.
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.
Created attachment 492421 [details] Log file from failed attempt.
Created attachment 492422 [details] Log file from successful attempt.
Retested h14 while sharing the two test LUNs, and that worked. I don't have another 4TB to try crosschecking the file size possibility.
CLosing per comment #7.