Bug 237456 - Existing LVM, Software Raid, and SATA disks not detected
Summary: Existing LVM, Software Raid, and SATA disks not detected
Alias: None
Product: Fedora
Classification: Fedora
Component: anaconda (Show other bugs)
(Show other bugs)
Version: rawhide
Hardware: i386 Linux
Target Milestone: ---
Assignee: Peter Jones
QA Contact: Will Woods
Depends On:
Blocks: FC7Blocker
TreeView+ depends on / blocked
Reported: 2007-04-23 11:22 UTC by Clyde E. Kunkel
Modified: 2007-11-30 22:12 UTC (History)
0 users

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Last Closed: 2007-05-25 19:49:24 UTC
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Attachments (Terms of Use)
LSPCI, PVSCAN, LVSCAN and MDADM output of working rawhide installation (4.52 KB, text/plain)
2007-04-23 11:22 UTC, Clyde E. Kunkel
no flags Details
LSPCI, PVSCAN and LVSCAN from attempted install of rawhide of 20070422 (3.98 KB, text/plain)
2007-04-23 11:24 UTC, Clyde E. Kunkel
no flags Details
/proc/partitions of working rawhide installation (2.16 KB, text/plain)
2007-04-23 15:14 UTC, Clyde E. Kunkel
no flags Details
dmesg of failed rawhide install (16.00 KB, text/plain)
2007-04-23 19:08 UTC, Clyde E. Kunkel
no flags Details
mdadm.conf from working rawhide installation (1018 bytes, text/plain)
2007-04-24 02:17 UTC, Clyde E. Kunkel
no flags Details
anaconda dump file from HTTP install of rawhide of 20070523 (63.11 KB, text/plain)
2007-05-24 03:51 UTC, Clyde E. Kunkel
no flags Details

Description Clyde E. Kunkel 2007-04-23 11:22:55 UTC
Description of problem: Trying to do a new fresh install from rawhide of
20070422 via network to a pre-existing software raid array.  Selected manual
partitioning and saw that existing LVs, software raid arrays and promise sata
drives not detected or were improperly detected.  The installation was attempted
on a machine used for testing and had a currently up-to-date rawhide
installation in one of the LVs in which the new /dev/sd* scheme works fine and
all raids and LVs are seen properly.  Attaching LSPCI, PVSCAN, LVSCAN and MDADM
output from the working rawhide installation and also LSPCI, PCVSCAN and LVSCAN
from the attempted new install install of rawhide.  MDADM reported no arrays. 
In addition, the promise sata drives looked like they were seen as a bios
enabled raid array; however, they are not.  They are enabled as individual ide

Version-Release number of selected component (if applicable): rawhide 20070422

How reproducible:
Every time

Steps to Reproduce:
1. boot boot.iso cd
2. select new installation
3. select mirror (duke)
4. work to setting up the partitions manually
5. see that existing raid arrays and LVs not seen
6. quit and BZ
Actual results: aborted installtion

Expected results: normal Fedora installtion on prexisting raid array

Additional info:

Comment 1 Clyde E. Kunkel 2007-04-23 11:22:56 UTC
Created attachment 153271 [details]
LSPCI, PVSCAN, LVSCAN and MDADM output of working rawhide installation

Comment 2 Clyde E. Kunkel 2007-04-23 11:24:43 UTC
Created attachment 153273 [details]
LSPCI, PVSCAN and LVSCAN from attempted install of rawhide of 20070422

Comment 3 Clyde E. Kunkel 2007-04-23 15:14:53 UTC
Created attachment 153286 [details]
/proc/partitions of working rawhide installation

Forgot to mention that /proc/partitions are very different between working,
established rawhide installation and the attempted new installation of rawhide
20070422.  Attached file is existing working rawhide and 15273 already has
/proc/partitions of attempted install of 20070422.

I was going to attempt to get the raid arrays working with rawhide 20070423 by
copying the working installation mdadm.conf to a location accessible to the
installer and then doing a mdadm --assemble --scan --config=/wheremdadm.confis;
however, with the differences in /proc/paritions, there is a good chance I
would render the arrays unusable for existing installations.

Comment 4 Dave Jones 2007-04-23 15:45:04 UTC
you mentioned on fedora-test-list..

"Strange thing is, I have a rawhide installation on the same machine that
I have kept up-to-date since FC6 final days and the disk detection and
libata work fine."

Which makes it sound like it isn't a kernel bug to me, but possibly either a bug
in anaconda, lvm or dmraid.

Comment 5 Clyde E. Kunkel 2007-04-23 19:08:00 UTC
Created attachment 153305 [details]
dmesg of failed rawhide install

Apologies for not doing this with rawhide of 20070422.	Tried rawhide of
20070423 and same issues as before; but, dmesg attached.  Seems suggestive. 
Also note that some raid arrays were created, but the partitioner indicated
that the file system was foreign.  I have seen this before when devices from
working pre-existing arrays are mismatched. dmesg of working rawhide
installation does not show any errors.

Comment 6 Dave Jones 2007-04-23 19:28:14 UTC
the lockdep errors are already filed in another bug, but that's not what's
preventing your install.   This seems to be confusion over which members of the
raidset go where judging by the chaos that happens when you start the array.

What does your /etc/mdadm.conf look like ?

Comment 7 Clyde E. Kunkel 2007-04-24 02:17:59 UTC
Created attachment 153329 [details]
mdadm.conf from working rawhide installation

Comment 8 Clyde E. Kunkel 2007-04-24 02:22:03 UTC
Per request in #6, /etc/mdadm.conf attached.

Comment 9 Clyde E. Kunkel 2007-04-24 21:32:41 UTC
Update with net install attempt of rawhide of 20070424.

Using nompath parameter allows the promise sata devices to be seen individually
instead of as a bios assembled array.  However, only one LV was seen and not all
software raid arrays were seen.  The ones seen still show the filesystem as foreign.

So, pressed back until opening install screen was up, went to console 2, mounted
a drive where I had put a valid mdadm.conf and did a mdadm --assemble --scan
--config=/temp/mdadm.conf and all arrays came up.  Then did an lvm vgchange -ay
and all LVs came up.  Back to console 6 and the partitioner now saw all LVs and
all software raid arrays and NO foreign file systems.  I did not continue with
the install since I had to "kludge" things to this point and I didn't know if
damage would be done.  On rebooting to the working rawhide installation, I
noticed that some of the 3rd devices in some of the raid5 arrays were missing,
but they re-added ok.  Hope this helps.

For the mdadm.conf file I changed DEVICE partitions to DEV /dev/sd*.  No other
changes from the attachment in #7.

Comment 10 Clyde E. Kunkel 2007-05-24 03:51:42 UTC
Created attachment 155311 [details]
anaconda dump file from HTTP install of rawhide of 20070523

Based on W. Woods list msg that mdadm now used, tried an HTTP install and
encountered an anaconda exception when it began looking for existing
installations.	Reran with nompath parm, but still failed.  This is actually a
regression over FC7T4 where you could work around software raid problems, but
not easily.

Also, don't know why this isn't a blocker.

Comment 11 Peter Jones 2007-05-24 15:11:35 UTC
Is this still broken in today's rawhide?  This appears to be a different symptom
of the bug fixed in #151653 .

Comment 12 Clyde E. Kunkel 2007-05-24 15:44:42 UTC
Haven't found an updated anaconda yet.  No msg in development list indicating
rawhide has been updated.  Fedora development dir at redhat has .63 version. 
Will try as soon as rawhide is updated.

Comment 13 Clyde E. Kunkel 2007-05-24 16:48:02 UTC
I really want to wait for a rawhide update msg, but did find a mirror that had
the .64 version of anaconda listed.  The images dir and files are dated 23 May,
so don't know if they include the new version of anaconda.  Anyway, tried an
HTTP install and got an anaconda traceback.  How do you determine the version of
anaconda during an install?  I tried -v and --version at console 2, but they
aren't valid parms.  Looked at the log, but didn't see any version information.
 Looked at the traceback file, but didn't see any version information.

Comment 14 Clyde E. Kunkel 2007-05-25 18:47:20 UTC
FC7RC2 DVD tested and with nompath parm added all pre-existing software raid and
LVs are seen.  Without nompath, the promise raid controller (which is *NOT*
configured as raid in the BIOS) is configured as a multipath controller and not
all software raid devices are correctly detected.  I don't know what is involved
in determining BIOS setting for these controllers--probably no standard across
the many BIOS'?--but maybe an option should be given to allow a user to select?
 Too sophisticated?

Also, I changed the mdadm.conf file to DEV /dev/sd* and used UUIDs instead of
major-minor.  I find UUIDs more precise and they are consistent across

Nice job tho, install went fine after nompath.  I consider this BZ closed, but
will leave final determination up to y'all.

Comment 15 Will Woods 2007-05-25 19:49:24 UTC
I think we'll consider this bug closed - if the Promise RAID stuff is a change
in behavior from FC6, you might file that as a separate bug.

Thanks for your help and patience.

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