If you have a volume group with two physical volumes called VolGroup00 and then you reformat one of the volumes as something else leaving only part of the volume group present, you can end up in a state where a) vgdisplay doesn't show that VolGroup00 exists (without parsing stderr anyway, which kind of defeats the purpose of having a well-formed output mode) sh-3.00# lvm vgdisplay Couldn't find device with uuid 'hM7BId-KfUk-IaA3-5Rgr-XOHP-U5Xu-DLrfDu'. Couldn't find all physical volumes for volume group VolGroup00. Volume group "VolGroup00" doesn't exist b) vgremove won't let you remove it even if it was detectable sh-3.00# lvm vgremove VolGroup00 Couldn't find device with uuid 'hM7BId-KfUk-IaA3-5Rgr-XOHP-U5Xu-DLrfDu'. Couldn't find all physical volumes for volume group VolGroup00. Volume group "VolGroup00" doesn't exist c) vgcreate won't let you create a new VolGroup00 sh-3.00# lvm vgcreate -v -An -s 32768k VolGroup00 /dev/sda2 Couldn't find device with uuid 'hM7BId-KfUk-IaA3-5Rgr-XOHP-U5Xu-DLrfDu'. A volume group called 'VolGroup00' already exists. This puts the installer in a position where there is *nothing* that I can do to get the user created with volume groups aside from switching the volgroup naming to be random (which is absurd). Yet another case where a --force option would be very useful.
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.