Bug 174047

Summary:	anaconda does not detect all raid sets, thus all VG and thus all LVs
Product:	[Fedora] Fedora	Reporter:	Clyde E. Kunkel <clydekunkel7734>
Component:	anaconda	Assignee:	Peter Jones <pjones>
Status:	CLOSED RAWHIDE	QA Contact:	Mike McLean <mikem>
Severity:	high	Docs Contact:
Priority:	medium
Version:	5
Target Milestone:	---
Target Release:	---
Hardware:	i386
OS:	Linux
Whiteboard:
Fixed In Version:	1/05/06	Doc Type:	Bug Fix
Doc Text:		Story Points:	---
Clone Of:		Environment:
Last Closed:	2006-01-06 01:24:14 UTC	Type:	---
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:	150221

Description Clyde E. Kunkel 2005-11-24 00:50:21 UTC

From Bugzilla Helper:
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7.12) Gecko/20051018 Fedora/1.7.12-2

Description of problem:
Second and third of three raid sets not detected and thus not all volume groups detected.

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

How reproducible:
Always

Steps to Reproduce:
1. boot FC5T1 cd 1
2. select create custom layout for disk partitioning
3. look for second VG (VolGroup1) so can mount logical volu

Actual Results: VolGroup1 not listed, md1 and md2 not listed. Only VolGroup0 and its LVs and the raidset it is on (md0).

md0, md1 are three device raid 5 and md2 is a two device raid 1.

Expected Results: All raid sets and all VGs and LVs should be seen.

Additional info:

The raid sets and logical volumes had been established on this multi-boot test machine. They were seen and detected by other distros. Not seen by an install of FC4 final also, did not bugzilla that incident.

Work around: open a second terminal and mdadm --assemble missing raid sets from already existing parts; lvm vgscan; lvm vgchange -a y VolGroup1; return to anaconda and all raidsets, VGs and LVs now seen.

Was able to create a third VG from a raidset now visible.

I don't know if this should be a second bug report, but; marked VolGroup1/FedoraHomes to be mounted on /home, no format (had done that previously with another distro). However, installer would not mount it, said probably not formatted and only allowed reboot at that time. Rebooted, repeated the workaround and did not mount anything other than VolGroup1 LVs and some hda partitions not part of LVM. Installation went fine after that.

Comment 1 Clyde E. Kunkel 2005-12-16 18:14:24 UTC

Installed from rawhide of 12/16/05.  Existing software raidsets are still not
detected.  These raidsets are used as PVs for LVs.

LVs were seen, but not those in VolGroup1.

Had to open a terminal and mdadm --assemble the raidsets.

On the first try install failed with the error msg "Error mounting device
VolGroup1/FedorHomes as /home.  This most likely means the partition has not
been formated.  Press OK to reboot your system."

Partition WAS formated before the install was attempted.

Retry without mounting FedoraHomes, and install succeeded however on firstboot
ran into the initrd problem that the raidsets were being called md_d0 and md_d1
instead of md0 and md1.

I cannot install Fedora Core unless I start from scratch.  This could be done,
but then I would have to redo days of work with other distros installed on the
test system.  Fedora Core rawhide should be installable on existing software
raidset/LV combinations without this problem.  I am changing severity to high
and would change priority to high if I had the ability since Fedora with
mkinitrd > 5.0.10 is not installable on this configuration.  If this
configuration is unusual, please tell me and I will go away.  However, LVs on
raid PVs does not seem unusual as there are clear advantages to using this
architecture which was setup to avoid data loss (raid 5 sets) and to allow easy
growth of partitions thru LVM2.

Comment 2 Clyde E. Kunkel 2006-01-06 01:24:14 UTC

Works with todays rawhide.  Thanks for fixing.