Red Hat Bugzilla – Bug 820203
Provide option to validate lvm.conf files and report unrecognised entries
Last modified: 2013-11-21 18:16:26 EST
People sometimes make mistakes when editing lvm.conf files and at the moment the tools do not report unrecognised entries. This aids compatibility between different versions. Perhaps there could be a new lvm.conf setting that, if enabled, would validate the file during startup and report unrecognised settings. (The list of settings would need to be generated automatically - I can think of several different ways this could be done.)
This request was not resolved in time for the current release. Red Hat invites you to ask your support representative to propose this request, if still desired, for consideration in the next release of Red Hat Enterprise Linux.
This request was evaluated by Red Hat Product Management for inclusion in the current release of Red Hat Enterprise Linux. Since we are unable to provide this feature at this time, it has been proposed for the next release of Red Hat Enterprise Linux.
The patchset is ready, will undergo a review soon I hope, but this is low prio RFE so only after 6.4 stuff is fully resolved...
Upstream commits 6ea68f233c2196856fbc008e30b1eb17deb62701 through 6b777ccbb5dca4a6d80b8b0bf071993c049f6a9f adds support for config validation. lvm.conf has a new "config" section with new "checks" and "abort_on_errors" options: # This section allows you to set the way the configuration settings are handled. config { # If enabled, any LVM2 configuration mismatch is reported. # This implies checking that the configuration key is understood # by LVM2 and that the value of the key is of a proper type. # If disabled, any configuration mismatch is ignored and default # value is used instead without any warning (a message about the # configuration key not being found is issued in verbose mode only). checks = 1 # If enabled, any configuration mismatch aborts the LVM2 process. abort_on_errors = 0 } Also, lvm dumpconfig has been enhanced to output several types of config trees: [1] raw/~ # lvm dumpconfig --help dumpconfig: Dump configuration dumpconfig [-f|--file filename] [--type {current|default|missing|new} [--withcomments] [--withversions] [--ignoreadvanced] [--ignoreunsupported] [--atversion version]] [--validate] [ConfigurationNode...] Where type is one of: - current: the original behaviour of lvm dumpconfig, just output existing lvm.conf/--config - default: output all possbile config nodes with default values - missing: output all missing config nodes that are not written in lvm.conf/--config (for which default values are used) - new: output all new options introduced in version that is defined by the --atversion arg (if --atversion is not specified, current version is assumed) --withcomments will add a short commentary on output for each config node if it was defined --withversions will add a commentary on output for each config node with an LVM version in which the config node appeared --ignoreadvanced will cause the output to not include any advanced nodes --ignoreunsupported will cause the output to not include any unsupported nodes (the ones which are targeted for internal or debug purposes only) --validate will validate the lvm.conf/--config on demand (no matter what the config/checks setting is set to) --- A few examples (pvs used, but works for all tools globally): (adding unrecognized global/abc setting while config/abort_on_errors=1 is used) [3] raw/~ # pvs Configuration setting "global/abc" unknown. LVM configuration invalid. (adding unrecognized global/abc setting while config/abort_on_errors=0 is used) [3] raw/~ # pvs Configuration setting "global/abc" unknown. PV VG Fmt Attr PSize PFree /dev/vda2 fedora_raw lvm2 a-- 19.51g 0 (using recognized global/umask setting, but with wrong type) [3] raw/~ # pvs Configuration setting "global/umask" has invalid type. Found string, expected integer. PV VG Fmt Attr PSize PFree /dev/vda2 fedora_raw lvm2 a-- 19.51g 0 (lvm dumpconfig enhancements) [3] raw/~ # lvm dumpconfig --type current config config { checks=1 abort_on_errors=1 } [3] raw/~ # lvm dumpconfig --type default config config { checks=1 abort_on_errors=0 } [3] raw/~ # lvm dumpconfig --type default config --withcomments # Configuration section config. # Configuration handling. config { # Configuration option config/checks. # Configuration tree check on each LVM command execution. checks=1 # Configuration option config/abort_on_errors. # Abort LVM command execution if configuration is invalid. abort_on_errors=0 } [3] raw/~ # lvm dumpconfig --type default config --withcomments --withversions # Configuration section config. # Configuration handling. # Since version 2.2.99. config { # Configuration option config/checks. # Configuration tree check on each LVM command execution. # Since version 2.2.99. checks=1 # Configuration option config/abort_on_errors. # Abort LVM command execution if configuration is invalid. # Since version 2.2.99. abort_on_errors=0 } [3] raw/~ # lvm dumpconfig --type new --withversions # Since version 2.2.99. config { # Since version 2.2.99. checks=1 # Since version 2.2.99. abort_on_errors=0 } # Since version 2.2.77. allocation { # Since version 2.2.99. thin_pool_zero=1 # Since version 2.2.99. thin_pool_discards="passdown" # Since version 2.2.99. thin_pool_chunk_size=64 } # Since version 1.0.0. log { # Since version 2.2.99. debug_classes=["memory", "devices", "activation", "allocation", "lvmetad", "metadata", "cache", "locking"] } # Since version 1.0.0. global { # Since version 2.2.99. raid10_segtype_default="mirror" # Since version 2.2.99. thin_disabled_features="" } # Since version 1.0.0. activation { # Since version 2.2.99. raid_region_size=512 } and so on...
Marking Verified with lvm2-2.02.103-0.100.el6 Users should be aware that the configuration tests are done after lvm.conf syntax checking, so that improper syntax inside the config file (unquoted string for example) would produce a syntax error rather than a configuration check error. Man page of lvm(8) as of this version does not contain explanations of each command line options. It is supposed to be added in a future version (it's still in the works).
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-2013-1704.html