> On 22 Dec 2016, at 11:17, jdow <[log in to unmask]> wrote:
> 
> On 2016-12-22 02:00, Stephan Wiesand wrote:
>>> On 22 Dec 2016, at 09:10, jdow <[log in to unmask]> wrote:
>>> 
>>> # yum install epel-release
>>> ....
>>> Transaction test succeeded
>>> Running transaction
>>> Traceback (most recent call last):
>>> File "/bin/yum", line 29, in <module>
>>>   yummain.user_main(sys.argv[1:], exit_code=True)
>>> File "/usr/share/yum-cli/yummain.py", line 365, in user_main
>>>   errcode = main(args)
>>> File "/usr/share/yum-cli/yummain.py", line 271, in main
>>>   return_code = base.doTransaction()
>>> File "/usr/share/yum-cli/cli.py", line 773, in doTransaction
>>>   resultobject = self.runTransaction(cb=cb)
>>> File "/usr/lib/python2.7/site-packages/yum/__init__.py", line 1736, in runTransaction
>>>   if self.fssnap.available and ((self.conf.fssnap_automatic_pre or
>>> File "/usr/lib/python2.7/site-packages/yum/__init__.py", line 1126, in <lambda>
>>>   fssnap = property(fget=lambda self: self._getFSsnap(),
>>> File "/usr/lib/python2.7/site-packages/yum/__init__.py", line 1062, in _getFSsnap
>>>   devices=devices)
>>> File "/usr/lib/python2.7/site-packages/yum/fssnapshots.py", line 158, in __init__
>>>   self._vgnames = _list_vg_names() if self.available else []
>>> File "/usr/lib/python2.7/site-packages/yum/fssnapshots.py", line 56, in _list_vg_names
>>>   names = lvm.listVgNames()
>>> lvm.LibLVMError: (0, '')
>> 
>> I saw similar errors on one SL7.2 system after applying the security updates from 7.3. Any lvmetad segfaults in your logs?
> 
> Oh interesting. There SHOULD be no LVM involved. It's a brandy spanky new install on btrfs. For the use I plan for this machine LVM is a wasteful extra layer of nonsense. So, of course, there they are.
> 
> ===8<---
> /var/log/messages:Dec 22 08:03:57 thursday lvmetad: WARNING: Ignoring unsupported value for cmd.
> /var/log/messages:Dec 22 08:03:57 thursday kernel: lvmetad[6113]: segfault at 500000000 ip 00007f8c92cfa528 sp 00007f8c90c70728 error 4 in libc-2.17.so[7f8c92bc7000+1b6000]
> /var/log/messages:Dec 22 08:03:57 thursday systemd: lvm2-lvmetad.service: main process exited, code=killed, status=11/SEGV
> /var/log/messages:Dec 22 08:03:57 thursday systemd: Unit lvm2-lvmetad.service entered failed state.
> /var/log/messages:Dec 22 08:03:57 thursday systemd: lvm2-lvmetad.service failed.
> /var/log/messages:Dec 22 08:03:57 thursday systemd: lvm2-lvmetad.service holdoff time over, scheduling restart.
> ===8<---
> 
> This raises the questions "Whyinell are they there and why is lvm2-lmvetad.service being enabled?" And "Howinell do I give it the proper kiss of death?"
> 
>> Eventually (I think after a couple of restarts of lvm2-lvmetad), the problem downgraded itself to a message "lvmetad: WARNING: Ignoring unsupported value for cmd." being logged whenever yum installs or updates anything and lvmetad is running. Still a bit scary, but yum works. And most of the time starting lvmetad seems to fail ayway...
> 
>>> 
>>> Can't get EPEL to install.
>>> 
>>> {^_^}
> 
> She whines, "But there should not be any lvm at all involved? What is it starting?"

Probably yum itself. I guess you want to

systemctl stop lvm2-lvmetad.service
systemctl stop lvm2-lvmetad.socket

This should give you back a working yum, though it will complain "WARNING: Failed to connect to lvmetad. Falling back to device scanning." now.

Next you probably want to disable (and maybe even mask) those units. Or "yum remove lvm2".

Sigh. Yet another of those useless caching daemons doing much more harm than good.

> {o.o}

-- 
Stephan Wiesand
DESY -DV-
Platanenallee 6
15738 Zeuthen, Germany