Description of problem: I had tagging set up on my cluster, and attempted to create a volume as: [root@z2 ~]# lvcreate -n lv -L 10G name Aborting. Failed to activate new LV to wipe the start of it Could the error message reflect the fact that lvcreate failed due to a tag conflict? The above error message sent me searching for untold errors/issues until I realized that it was due to a leftover tag from testing.
If you define a tag, that's another namespace prefixed by '@'. It should not conflict with proper LV/VG names so I think the LV activation failure should not be caused by tagging. Could you be more specific in the definition of "tag conflict"? Does it really mean that only removing existing tag caused the lvcreate command to succeed?
This was absolutely caused by the left over tag. When you have a tag such as this for HA LVM, all activation will fail unless you have that tag in the VG. volume_list = [ "VolGroup00", "@node_name" ] A customer has run into this issue now as well. We need an actual error saying something like "Hey dummy, we can't activate this volume because it doesn't have the proper tag". Besides, what does, "Failed to activate new LV to wipe the start of it" even mean? It's not even proper English.
Ah, I see... Actually there's one line in verbose output related to this that says: "Not activating vgname/lvname due to config file settings" It does not give much help in this situation anyway, I have to admit :) The strange looking error message about failed activation and wipe is just a consequence of failing the activation filter (..first few sectors of new LVs are wiped with zeroes). OK, I'll have a look if we can make the messages less confusing here...
It's hard to be specific without generating warnings when people don't want them - verbose-level is probably right. (Two independent parts of the code are involved.) Changing the original message to mention it might be due to tags should be fine. It could actually check if activation/volume_list is defined and give a second message if it is. "This may be due to the volume_list setting in the activation section of your lvm configuration."
OK, I've added a few messages: If activation/volume_list IS NOT defined: "activation/volume_list configuration setting not defined, checking host tags only" ... "No host tag matches <vgname>/<lvname>" If activation/volume_list IS defined: "activation/volume_list configuration setting, defined, checking the list to match <vgname>/<lvname>" ... "No item supplied in activation/volume_list configuration setting matches <vgname>/<lvname>" That should provide enough info about what's going on and people should be able to trace the problem easily. The messages are seen in verbose output with "-v" now. (scheduled for upstream release v2.02.71)
Fix in lvm2-2.02.73-1.el5.
Seems like the same error message still appears in lvm2-2.02.74-1.el5. volume_list = [ "VolGroup00", "@node_name" ] [root@taft-01 ~]# lvcreate -m 1 --corelog -n mirror2 -L 1G taft Aborting. Failed to activate new LV to wipe the start of it.
(In reply to comment #9) > Seems like the same error message still appears in lvm2-2.02.74-1.el5. > > volume_list = [ "VolGroup00", "@node_name" ] > > [root@taft-01 ~]# lvcreate -m 1 --corelog -n mirror2 -L 1G taft > Aborting. Failed to activate new LV to wipe the start of it. There's more info in verbose output: lvcreate -m 1 --corelog -l 1 vg -vvv ... activation/volume_list configuration setting defined, checking the list item to match vg/lvol0 activation/volume_list configuration setting defined, checking the list item to match vg/lvol0 No item supplied in activation/volume_list configuration setting matches vg/lvol0 Not activating vg/lvol0 due to config file settings Aborting. Failed to activate new LV to wipe the start of it. (...hmm, maybe I should add what is being checked in the "checking the list item" message - which volume_list item) But I kept the last message "Aborting. Failed to activate new LV to wipe the start of it." Or do you want to reformulate it? (I like this wording bugs... :))
If it's an LV that doesn't need to be wiped, there's only a message: "Failed to activate new LV." If that LV needs to be wiped in addition, we show a more detailed error message: "Failed to activate new LV to wipe the start of it." (So we can decide on code path that is problematic when debugging. But yes, maybe the sentence sounds a little bit strange :))
This bug is about improving the current error message, so I'm surprised that it hasn't changed at all, or that there was confusion about whether or not the fix should change it. Also, I don't think the verbose messages really give that much more information. In a perfect world, I think that if the volume can't be created/activated because it's VG doesn't have the proper tag, then the error message should reflect that. Something like "Unable to create/activate logical volume due to improper or missing VG tag." I realize that is easier said than done based on lvm activation logic. The fact remains that "Failed to activate new LV to wipe the start of it." is not proper english (not that all errors need to be) and doesn't actually mean anything. It's gibberish.
Well, we use exactly the same check for testing only (not necessarily failing) the activation so changing these verbose messages into error messages is not a good idea. However, I'd probably leave out the "..to wipe the start of it" part of the error message since this has no information gain for a user. Also, I'd change one message from verbose to error level. So now, when the activation filter (which is hosttags or activation/volume_list) fails, we will show: # lvcreate -l1 vg1 Not activationf vg1/lvol1 since it does not pass activation filter. Failed to activate new LV. If the user wants to know more info, he can just use verbose level: # lvcreate -v -l1 vg1 ... Found volume group "vg1" activation/volume_list configuration setting defined, checking the list to match vg1/lvol1 No item supplied in activation/volume_list configuration setting matches vg1/lvol1 Not activating vg1/lvol1 since it does not pass activation filter. Failed to activate new LV. ... So is this error/verbose scheme acceptable? There's nothing else to report, I think - activation fails because it does not pass activation filter and that one fails either because of the "host tags" or firm activation/volume_list setting. (I can't put all the info in one error message - there could be even more causes of the activation failure and, at the same time, we reuse some parts of the code for testing only whether it passes some condition or not, not failing.)
(In reply to comment #13) > # lvcreate -l1 vg1 > Not activationf vg1/lvol1 since it does not pass activation filter. "Not activating...", of course...
(In reply to comment #12) > Something like "Unable to create/activate logical volume due to > improper or missing VG tag." Hmm, it's fine to have improper or missing VG tag, we can still define VG itself or VG/LV directly in the activation/volume_list. I think the verbose messages are just fine - they're pointing the user to check exactly the place we need and then he should make any corrections if needed.
The suggestion in comment #15 works for me, anything is better than "to wipe the start of it."
OK, checked in (2.02.76).
And in lvm2-2.02.74-2.el5.
Fix verified in lvm2-2.02.74-2.el5. [root@taft-01 ~]# lvcreate -m 1 --corelog -n mirror2 -L 1G taft Not activating taft/mirror2 since it does not pass activation filter. Failed to activate new LV.
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 therefore 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-2011-0052.html