Bug 139058 (IT_54714:IT_55916)
Summary: | Partially deleted volume groups cause inability to detect or remove or create a new one | ||
---|---|---|---|
Product: | Red Hat Enterprise Linux 4 | Reporter: | Jeremy Katz <katzj> |
Component: | lvm2 | Assignee: | Jeremy Katz <katzj> |
Status: | CLOSED RAWHIDE | QA Contact: | |
Severity: | high | Docs Contact: | |
Priority: | medium | ||
Version: | 4.0 | CC: | brian.b, glen.foster, jbarnes, jlaska, jturner, ltroan, picochico, prarit, shillman, tao |
Target Milestone: | --- | ||
Target Release: | --- | ||
Hardware: | All | ||
OS: | Linux | ||
Whiteboard: | |||
Fixed In Version: | Doc Type: | Bug Fix | |
Doc Text: | Story Points: | --- | |
Clone Of: | Environment: | ||
Last Closed: | 2005-02-10 14:53:11 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: | 140583 |
Description
Jeremy Katz
2004-11-12 19:12:04 UTC
But where does the pvcreate fit into that? lvm2 works on the principle that tools will not automatically change any metadata if they find serious inconsistencies - otherwise they might destroy data that needed recovering not destroying. Metadata must be made consistent again using recovery tools or --force options first. The tools can't be allowed to vgcreate a VG if there's a PV already present that thinks it's in a VG together with another PV that has gone missing in an uncontrolled way (e.g. by removing the disk or overwriting it or changing lvm filters or by using a --force option). All the remnants of the old VG must be removed first, e.g. with pvremove or pvcreate -ff (followed by a vgscan for good measure). Also, in lvm2, parsing of XXdisplay output should be avoided as the format is meant to be user-readable and is liable to be changed - vgs, lvs & pvs provide a stable format that should be used instead. Let's make time to walk through the anaconda/lvm2 interactions in Boston and see what needs to change on both side to make them even more robust. *** Bug 138224 has been marked as a duplicate of this bug. *** *** Bug 139418 has been marked as a duplicate of this bug. *** Bug 139418 was on rc1 BLOCKER list. This bug is SHOULDFIX. Per RH Engineering meeting last Tuesday, Jeremy feels this is a SHOULDFIX rather than a ship blocker and that a knowledgebase entry should be sufficient if the fix does not make rc1. We are seeing this as well. Why is this a shouldfix instead of a blocker? This means if a customer tries to install RH EL 4 over a drive that's been used before, the install may fail. Another precint heard from: customers could ultimately see a brand-new system with a completely new, shiny set of CDs barf on the first install. Not a good first impression. I agree with Brian (and with my initial recommendation) that this is a MUST-fix. Please consider re-prioritizing this higher. Discussed in Westford last week: there's a --partial flag anaconda can pass to the lvm2 tools to detect incomplete VGs and then it can know to use a different vg name that doesn't conflict. And added the implementation to use --partial Is there a way we can test this before pre-rc2? I'm looking at the holiday schedule and noticing there's not much time then...I've also got another issue that I think is a duplicate of this but not sure and would like to try this fix for it as well. From Rick Hester at HP in Issue Tracker: ------- Additional Comment #6 From Rick Hester (rick.hester) on 2004-12-23 12:56 ------- Installed with rhel4prerc2 on a system where all the partition tables had been removed with parted. No traceback occurred. ------- Additional Comment #7 From Rick Hester (rick.hester) on 2004-12-24 15:20 ------- I spoke too soon. Comment 6 was with an install onto an rx8620. But an install to an rx1600 with blank disks does create a traceback - using rhel4 pre-RC2 bits. Installation was to sda with partitioning defaults supplied by Autopartition. sdb, sdd - sdp were all free space. I will attach console output in case it is helpful. See Bug 139418 ... all tracebacks are not created equal. You could be hitting a completely different traceback, but without it attached, it's impossible to say. Larry, this is something *COMPLETELY DIFFERENT*. Can we close this one out? I think we can, but just checking. |