Created attachment 821248 [details] vdsm Description of problem: Trying to create new block SD using is22 fails due to new vgcreate parameter (--ignoreskippedcluster) in case using old lvm version Version-Release number of selected component (if applicable): is22 vdsm-4.13.0-0.6.beta1.el6ev lvm2-2.02.100-3.el6 How reproducible: 100% Steps to Reproduce: 1. create new block storage domain when host installed with lvm2-2.02.100-3.el6 workaround: upgrade lvm2 to lvm2-2.02.100-8.el6 Actual results: create fails Expected results: when installing vdsm it should upgrade the lvm version. Additional info: Thread-60::DEBUG::2013-11-07 17:39:10,488::lvm::309::Storage.Misc.excCmd::(cmd) FAILED: <err> = "vgs: unrecognized option '--ignoreskippedcluster'\n Error during parsing of command line.\n"; <rc> = 3
dist-git's vdsm.spec should be updated so that it matches rhev-3.0's branch on gerrit.eng.lab.
how is that relevant to the bug? and i don't understand what change you expect to be on the spec file?
The vdsm.spec in dist-git has Requires: lvm2 >= 2.02.95-10.el6_3.2 but Federico has changed that to Requires: lvm2 >= 2.02.100-5 Please do a regular vimdiff between the two (I think that my old prebrew script used to do that). Currently you have a similar problem with libvirt. I believe that we are better off since you have not taken http://gerrit.ovirt.org/#/c/20489/ into the build, so you may want to keep it out; please discuss this latter issue with Yaniv first.
yes, i found that out after you mentioned it and i verified it by looking at the src rpms of vdsm. we fixed the spec file on distgit, but imo i think using vimdiff is an open for such bugs and problems. we should automate this process ASAP, i don't see a reason to do this manually. every patch that changes spec file should get it and applied, and since we know the lines that are unique to distgit, this shouldn't be a problem. i've asked kiril to start thinking on automating this. as for http://gerrit.ovirt.org/#/c/20489/, it's already in, i strongly disagree on hacking manually the spec file and deciding what goes into distgit and what not. if you believe it shouldn't get it, we should put a revert patch in the d/s patches for it.
fixed. 4.13.0-0.9.beta1.el6ev.x86_64
This bug is currently attached to errata RHBA-2013:15291. If this change is not to be documented in the text for this errata please either remove it from the errata, set the requires_doc_text flag to minus (-), or leave a "Doc Text" value of "--no tech note required" if you do not have permission to alter the flag. Otherwise to aid in the development of relevant and accurate release documentation, please fill out the "Doc Text" field above with these four (4) pieces of information: * Cause: What actions or circumstances cause this bug to present. * Consequence: What happens when the bug presents. * Fix: What was done to fix the bug. * Result: What now happens when the actions or circumstances above occur. (NB: this is not the same as 'the bug doesn't present anymore') Once filled out, please set the "Doc Type" field to the appropriate value for the type of change made and submit your edits to the bug. For further details on the Cause, Consequence, Fix, Result format please refer to: https://bugzilla.redhat.com/page.cgi?id=fields.html#cf_release_notes Thanks in advance.
This bug is due to a temporary build system glitch. It has no customer-facing effect and thus, should not be documented.
Yep, it's missing from 3.2.z: http://pkgs.devel.redhat.com/cgit/rpms/vdsm/tree/vdsm.spec?h=rhevm-3.2-rhel-6#n107
Since the problem described in this bug report should be resolved in a recent advisory, it has been closed with a resolution of ERRATA. For information on the advisory, and where to find the updated files, follow the link below. If the solution does not work for you, open a new bug report. http://rhn.redhat.com/errata/RHBA-2014-0040.html