Red Hat Bugzilla – Bug 1475018
Downgrading LVM2 from 7.4 to 7.3 causes "Invalid units specification" in every command
Last modified: 2017-08-05 09:53:45 EDT
+++ This bug was initially created as a clone of Bug #1452932 +++
Description of problem:
This issue affects libguestfs in RHEL 7.4.
If you use the configuration file from lvm2 >= 2.02.171 with any earlier
lvm2, all lvm utilities break with the error:
Invalid units specification
This happens because lvm.conf contains:
# Default value for --units argument.
units = "r"
The problem is that the very slightly older version of LVM2
doesn't understand this, and worse than that, every command -- even
ones that don't care about units, such as lvs --help --
fails with the mysterious error message:
Invalid units specification
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
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
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):
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).
(In reply to Richard W.M. Jones from comment #9)
> Empty lvm.conf seems to work fine. I posted patches (for libguestfs):
These are upstream in:
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. ***