How did the situation arise?  Just guessing, but was this 7.3->7.4; edit something in lvm.conf; then 7.4->7.3?  Was any .rpmnew file created but ignored?  We'll then have a think about whether any spec file changes could improve the way cases like these get handled in future.

The error message goes back 15 years and certainly needs to be improved to explain what it's talking about!

It's to do with how libguestfs caches a copy of lvm.conf during builds.
This means (because of the randomness of global brew build-overrides) that
we either cache the copy from >= 2.02.171 [bad] or < 2.02.171 [good].

We can't use the host copy of the config file because it might have
administrator changes that would break libguestfs.

Really the problem here is that the units line should be commented out,
since "r" is the default setting (see also commit f8234d6e5).

To be quite clear, there is no requirement for the 7.3 package to understand the config file shipped with 7.4, and it's safer to stop to let the user finish their incomplete downgrade procedure than to continue and ignore new things the old package doesn't understand.

The issue here is how the user managed not to be aware that the file needed manual attention after downgrading i.e. what additional notifications might be possible and whether there are some cases that could be covered by better rpm scriptlets.  (For example, if this situation can ever arise when only default config files are in use.)

(In reply to Richard W.M. Jones from comment #3)
> It's to do with how libguestfs caches a copy of lvm.conf during builds.

Then we need to understand this better and work out how to fix the dependencies.

> We can't use the host copy of the config file because it might have
> administrator changes that would break libguestfs.

So what is it used for?  Is it edited at all or is libguestfs really trying always to run with the built-in settings and not use a config file at all?

lvm2 does not support easy 'downgrade' in terms - you can take any 'newer' configuration file  and use it with old version of lvm2.

It's even more important if you write NEW lvm2 metadata with new command,
and you would expect such new format would be fully usable with older version
of lvm2.


Nowadays lvm2 fully supports execution of  lvm2 command without any configuration file at all - since all settings are built-in and are embedded in the binary and even fully exposable with 'lvm config' command.

So we have:

1.  lvm2 should probably distribute minimal config file (possibly referring man pages and the way how to generate it

2.  User should change minimal amount of thing in configure

3.  lvm2 of course cannot 'just' ignore whatever user has set for a setting -  but ATM lvm2 has no idea from where the unknown setting came from - since it could have been users' setting or uncommented default from installation - but it's clear the configured settings needs to be respected - since they are configure command to do some operation in described way - so lvm2 should not in general auto magically discard them without knowing what they are for (i.e. older version does not understand new option value)

4. There are settings with different degree of influence - so i.e.  ignoring  'units' with invalid value - probably has different impact the ignoring invalid i.e. filter setting -  so lvm2 may probably do a more fail-safe acceptance of some values for those 'less important' settings -  we need to identify them...
IMHO  units is rather  WARNING level then error level.

(In reply to Alasdair Kergon from comment #5)
> So what is it used for?  Is it edited at all or is libguestfs really trying
> always to run with the built-in settings and not use a config file at all?

It's used to construct the appliance.  We can't use the one from the
host because it could contain arbitrary changes, and we cannot download
the virgin config file at the point that the appliance gets built on the
end user machine.

However I did learn a couple of things from comment 6: (1) that no
config file is really needed and (2) the 'lvm config' command.  We
can probably work around this by adding:

rm -f /etc/lvm/lvm.conf

and/or

lvm config > /etc/lvm/lvm.conf

to the appliance init script.

> lvm2 does not support easy 'downgrade' in terms - you can take any
> 'newer' configuration file  and use it with old version of lvm2.

libguestfs doesn't expect or need this, but the problem is with global
buildroot overrides where we get some arbitrary new version of lvm2
when we didn't ask for it.

Yes, you're looking for something like 'lvm config --type default --unconfigured --withcomments --ignorelocal --withspaces' plus the page of preamble at the start of the file.  (We can probably add an option to produce that too.)

Empty lvm.conf seems to work fine.  I posted patches (for libguestfs):

https://www.redhat.com/archives/libguestfs/2017-July/msg00285.html

Updated message upstream now:
  Unrecognised configuration setting for global/units: z
and fixed exit status code to a (re-used) 4 (was -1 which showed as 255).

https://www.redhat.com/archives/lvm-devel/2017-July/msg00164.html
https://www.redhat.com/archives/lvm-devel/2017-July/msg00165.html

https://sourceware.org/git/?p=lvm2.git;a=commitdiff;h=3654f478e1beab950f9ee91bc2fd759d22552e1c
https://sourceware.org/git/?p=lvm2.git;a=commitdiff;h=54f5bc01b9509f80b3e8fe16f8bb1bc0228265ab

(In reply to Richard W.M. Jones from comment #9)
> Empty lvm.conf seems to work fine.  I posted patches (for libguestfs):
> 
> https://www.redhat.com/archives/libguestfs/2017-July/msg00285.html

These are upstream in:
https://github.com/libguestfs/libguestfs/commit/10cf01419aff4d7913d1a3011ec0f1ba11afe0c9

Thanks Alasdair, feel free to close this bug or reassign to libguestfs
if you want.

*** Bug 1478226 has been marked as a duplicate of this bug. ***