In general I would suggest fully disabling lvmetad from the config files and from being started up. Issues around it not answering (like above) and answering but somehow having stale/wrong info have burned me too many times to trust it. It may be a lvmetad bug, or be udevd weirdness. The only significant improvement it makes is it reduces the lvm command time on installs with significant numbers of devices, but given that the info has been wrong often enough that is not worth the risk. On Mon, Sep 14, 2020 at 2:25 AM KrishnaMurali Chennuboina <krishchennu414@xxxxxxxxx> wrote: > > Hi Team, > > While trying to analyze one the issue, we felt that upgrading the current LVM2 package in our repository will be the best approach. > As part of that, we have updated the respective package from 2.02.176 to 2.02.180. We have verified the same and booted x86_64 hardware without any issues. > > But while trying to boot mips64 hardware we have started observing the below issue. Providing the snippet of the log, > > # executing command: vgchange -an > (status, output): (0, WARNING: Failed to connect to lvmetad. Falling back to device scanning.) > WARNING: Failed to connect to lvmetad. Falling back to device scanning. > > Attached the detailed log for reference. There is no other change included other than the LVM2 update. > > LVM2 Version: 2.02.176 > Updated LVM2 version: 2.02.180 > > Please share inputs on why this issue is being observed with .180 version? > Please let me know if i can share any other information. > > Thanks. > > _______________________________________________ > linux-lvm mailing list > linux-lvm@xxxxxxxxxx > https://www.redhat.com/mailman/listinfo/linux-lvm > read the LVM HOW-TO at http://tldp.org/HOWTO/LVM-HOWTO/ _______________________________________________ linux-lvm mailing list linux-lvm@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/linux-lvm read the LVM HOW-TO at http://tldp.org/HOWTO/LVM-HOWTO/
