Description of problem: [root@link-08 ~]# pvscan No matching physical volumes found [root@link-08 ~]# pvremove /dev/sda2 No physical volume label read from /dev/sda2 Labels on physical volume "/dev/sda2" successfully wiped [root@link-08 ~]# echo $? 0 If there's no physical volume label read, then what exactly is it successfully wipping? Version-Release number of selected component (if applicable): [root@link-08 ~]# pvremove --version LVM version: 2.02.01 (2005-11-23) Library version: 1.02.02 (2006-01-04) Driver version: 4.5.0
It's not so much the message that's wrong, it's the fact that if there are no labels there it would be safer to do nothing (and exit with success).
*** Bug 180763 has been marked as a duplicate of this bug. ***
If I run pvremove on the same disk twice in succession, I want it to exit with success both times, but only to write something to the disk the first time. In line with my earlier comment, the message can be suppressed if nothing was written. When I run pvremove I'm only interested in the *final state* after the command ran, not any actions the command itself took. When I run pvremove, my intention is "make sure this disk is not recognised by LVM2 as a PV". So I get 'success' if that is true; 'failure' if it isn't. I'll expand the man page to explain this. If there's disagreement on this point and someone can justify wanting to know from the return code whether or not any label had to be wiped then I'll set about making it a configurable option.
I disagree, why not make that same argument in the following cases then? [root@link-08 bin]# lvremove -f /dev/stripe_1_9746/stripe_1_97460 Logical volume "stripe_1_97460" successfully removed [root@link-08 bin]# echo $? 0 [root@link-08 bin]# lvremove -f /dev/stripe_1_9746/stripe_1_97460 One or more specified logical volume(s) not found. [root@link-08 bin]# echo $? 5 [root@link-08 bin]# vgremove stripe_1_9746 Volume group "stripe_1_9746" successfully removed [root@link-08 bin]# echo $? 0 [root@link-08 bin]# vgremove stripe_1_9746 Volume group "stripe_1_9746" not found or inconsistent. Consider vgreduce --removemissing if metadata is inconsistent. [root@link-08 bin]# echo $? 5 [root@link-08 tmp]# rmdir lvm [root@link-08 tmp]# echo $? 0 [root@link-08 tmp]# rmdir lvm rmdir: `lvm': No such file or directory [root@link-08 tmp]# echo $? 1 [root@link-08 tmp]# rm goo rm: remove regular empty file `goo'? y [root@link-08 tmp]# echo $? 0 [root@link-08 tmp]# rm goo rm: cannot lstat `goo': No such file or directory [root@link-08 tmp]# echo $? 1
The difference is that with the PV operations the focus of the commands is on the final state not the process needed to reach it: ensuring that a device is or is not recognised as usable by LVM. Running the commands repeatedly causes no problems and is a common thing for people to do. If I run 'pvcreate' or 'pvremove' twice the system ends up in the state requested so the command succeeds - if it failed the second time that would cause unnecessary annoyance. VG and LV operations on the other hand are concerned with manipulating structures in namespaces - if I attempt to remove a logical volume that doesn't exist I *do* want to be told. If I change this, it will cause some people's scripts to fail for no good reason. A compromise might be to use the '--force' flag to let people choose the behaviour they prefer: to give an error without the flag, but success with it.
Committed upstream.
pvremove without -f now fails if there's no PV label.
fix verified.
An advisory has been issued which should help the problem described in this bug report. This report is therefore being closed with a resolution of ERRATA. For more information on the solution and/or where to find the updated files, please follow the link below. You may reopen this bug report if the solution does not work for you. http://rhn.redhat.com/errata/RHBA-2006-0504.html