Bug 169986
| Summary: | vgscan/vgchange can't transition partial VG to full | ||
|---|---|---|---|
| Product: | [Fedora] Fedora | Reporter: | Alexandre Oliva <oliva> |
| Component: | lvm2 | Assignee: | LVM and device-mapper development team <lvm-team> |
| Status: | CLOSED NOTABUG | QA Contact: | |
| Severity: | medium | Docs Contact: | |
| Priority: | medium | ||
| Version: | rawhide | CC: | agk, dwysocha, mbroz, triage |
| Target Milestone: | --- | Keywords: | FutureFeature |
| Target Release: | --- | ||
| Hardware: | All | ||
| OS: | Linux | ||
| Whiteboard: | |||
| Fixed In Version: | Doc Type: | Enhancement | |
| Doc Text: | Story Points: | --- | |
| Clone Of: | Environment: | ||
| Last Closed: | 2010-06-23 11:41:37 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: | |||
|
Description
Alexandre Oliva
2005-10-06 04:42:11 UTC
The partial VG flags are there to help recovery - they should not be used routinely! "Unfortunately, that approach was a major failure, and we had to go back to bringing up all PVs in the volume group." Correct. Lvm2 considers the VG to be the unit and you must bring up all the PVs in the VG before using lvm2 commands. If you don't want to bring up all the PVs initially, then split them off into a different VG. "mkinitrd has recently started experimenting loading modules and started raid devices that are minimally enough to get the PVs containing the root filesystem up and running." If anyone had asked about this, here is how to do this in a way that *is* supportable by lvm2 (current cvs version allows for creating PVs on LVs): vg0 consists of real disks pv0 and pv1 - minimum requirement for the root filesystem. vg0 contains rootlv with root filesystem and freespacelv with all the remaining space. pvcreate is run on freespacelv to create pv2. vg1 is created as pv2 + remaining pvs and used to hold remaining disk volumes. [Over time this will get nicer as the definition of a VG evolves and stacked VGs become commonplace.] Supporting recovery (semi-)automatically when PVs have disappeared permanently is a separate issue which 'vgck' needs to be written to address. Based on the date this bug was created, it appears to have been reported against rawhide during the development of a Fedora release that is no longer maintained. In order to refocus our efforts as a project we are flagging all of the open bugs for releases which are no longer maintained. If this bug remains in NEEDINFO thirty (30) days from now, we will automatically close it. If you can reproduce this bug in a maintained Fedora version (7, 8, or rawhide), please change this bug to the respective version and change the status to ASSIGNED. (If you're unable to change the bug's version or status, add a comment to the bug and someone will change it for you.) Thanks for your help, and we apologize again that we haven't handled these issues to this point. The process we're following is outlined here: http://fedoraproject.org/wiki/BugZappers/F9CleanUp We will be following the process here: http://fedoraproject.org/wiki/BugZappers/HouseKeeping to ensure this doesn't happen again. inappropriate bug zapper comments there is work in progress helping to improve the automated recovery options adding "bug zapper repellent" keyword of FutureFeature as it sounds like that is what this is :) Seems that this old BZ covers no special "festure", so closing it. (vgck implementation is tracked by bug #185526, using of partial flag is explained in comment #1, moreover this situation is now solved in dracut, somehow;-) Also lvm should autorecover re-appeared PVs with old metadata now. |