Bug 551707 - [Fedora12] existing LVM group is not visible during installation
[Fedora12] existing LVM group is not visible during installation
Product: Fedora
Classification: Fedora
Component: lvm2 (Show other bugs)
All Linux
low Severity medium
: ---
: ---
Assigned To: LVM and device-mapper development team
Fedora Extras Quality Assurance
Depends On:
  Show dependency treegraph
Reported: 2010-01-01 07:35 EST by dekel35
Modified: 2010-01-02 11:47 EST (History)
10 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Last Closed: 2010-01-02 11:47:34 EST
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Attachments (Terms of Use)
Ouput log from console started during installation (41.81 KB, text/plain)
2010-01-01 07:35 EST, dekel35
no flags Details

  None (edit)
Description dekel35 2010-01-01 07:35:11 EST
Created attachment 381174 [details]
Ouput log from console started during installation

Description of problem:
Problem might be related to bugid 551705
After starting a raid0 array (created in Fedora 11) the volume group does not start under Fedora 12. This does not happen in Fedora 11, and in other distribution installation procedures (e.g., ubuntu). 

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

How reproducible:
see steps to reproduce

Steps to Reproduce:
1. create raid0 and and a volume group on top in Fedora 11
2. try to install Fedora 12 on that raid
Actual results:
volume group can not be made active

Expected results:
Volume group is active

Additional info:

# lvm vgchange -a y
(i.e., no output)

See attachment for full output
Comment 1 dekel35 2010-01-01 07:37:31 EST
see bug#551705 re the raid problem. thx.
Comment 2 Milan Broz 2010-01-02 09:44:43 EST
After starting MD array you have to use "vgscan" to rescan new devices _or_
specify VG explicitly (to force scan for that VG).

lvm vgscan
lvm vgchange -a y  <VG_name>

(VG name, not PV path! The second vgchange in your log has wrong syntax.)

(But according to log, I think there is some misconfiguration on your system,
there is existing partition on that MD device - /dev/md0p1 and no lvm2 label is detected there anyway. If you have PV directly on /dev/md0, you have to remove that partition table signature. Kernel MD driver started to recognise partitions on MD in some recent version, maybe that's the reason why F11 works.)
Comment 3 dekel35 2010-01-02 11:47:34 EST
Indeed the existence of the partition (md0p1) caused this problem (especially since the raid was created anyway without a partition).  
one I deleted that partition (which I have no idea how it was created), the installation went without a problem (or at least the lvm is visible again without doing any vgscan or vgchange). 

Problems can be closed.

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