On 02/05/2014 10:41 AM, Patrick Shanahan wrote:
* Robert Schweikert
[02-05-14 09:12]: On 02/05/2014 08:25 AM, Anton Aylward wrote:
On 02/04/2014 10:52 AM, Andrey Borzenkov wrote:
Actually, intended solution is "systemctl enable lvm2-lvmetad.socket"
What about lvm2-lvmetad.service ? Should that be enebaled too?
NO, only enable lvm2-lvmetad.socket if you are going down that route.
After recovering my Tumbleweed to a semi-normal state, I enabled lvm2-lvmetad.socket and shortly thereafter received a downgrade to lvm2-2.02.98-0.28.1.5.x86_64 which disabled lvmetad.socket.
So *what* is correct?
all 5 of my local installs, four TW and one 13.1, show lvmetad.socket "disabled", inactive (dead)
It all depends on the value in the config file. I suspect that the downgrade set use_lvmetad = 0 in /etc/lvm/lvm.conf while the previous update set the value to 1. So this is what I have gathered based on reading through the bug reports, https://bugzilla.novell.com/show_bug.cgi?id=862076 https://bugzilla.redhat.com/show_bug.cgi?id=837603 answers to this thread, and my own observation. When toggling the value of use_lvmetad either on or off one needs to make certain that the daemon is not running. In either case cache data will be remembered and there'll be no booting the next time around. If you want to use the daemon the following procedure should work: - stop all lvmetad services (.socket and .service) - toggle the flag in the config file - start the lvmetad.service and lvmetad.socket - enable lvmetad.socket The .service should not be enabled, as I understand it, as it will cause problems. The .socket will do the trick when the system is booted and things are expected to work. I have not dug into the details why this is the case and will probably not find the time to do so. To operate as previously, i.e. before the mess started - stop all lvmetad services (.socket and .service) - disable lvmetad.service and lvmetad.socket - set use_lvmetad = 0 - reboot Unless of course you have already forced recognition of your volumes with lvmetad daemon. The you run into the cache issue and the RH bugreport has the details on how to recover. HTH, Robert -- Robert Schweikert MAY THE SOURCE BE WITH YOU SUSE-IBM Software Integration Center LINUX Tech Lead Public Cloud Architect rjschwei@suse.com rschweik@ca.ibm.com 781-464-8147 -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org