Description of problem: For testing / debugging of OpenStack, a volume group with a file-backend is often created, e.g. https://fedoraproject.org/wiki/QA:Testcase_Create_Cinder_Volumes Now, it looks like after a reboot, the PV and VG created like this are no longer recognized by pvscan/vgscan/pvchange/vgchange. Version-Release number of selected component (if applicable): lvm2-2.02.98-11.fc19.x86_64 How reproducible: Always(?) Steps to Reproduce & results: [root@openstack ~]# truncate -s1G test [root@openstack ~]# losetup -f --show test /dev/loop1 [root@openstack ~]# vgcreate test /dev/loop1 No physical volume found in lvmetad cache for /dev/loop1 Physical volume "/dev/loop1" successfully created Volume group "test" successfully created [root@openstack ~]# vgscan Reading all physical volumes. This may take a while... Found volume group "test" using metadata type lvm2 [root@openstack ~]# sync [root@openstack ~]# losetup -d /dev/loop1 [root@openstack ~]# reboot Connection to 192.168.0.158 closed by remote host. Connection to 192.168.0.158 closed. [red_trela@tiphares ~]$ ssh root.0.158 root.0.158's password: Last login: Fri Aug 16 14:41:13 2013 from 192.168.0.1 [root@openstack ~]# losetup -f --show test /dev/loop1 [root@openstack ~]# vgscan Reading all physical volumes. This may take a while... No volume groups found [root@openstack ~]# pvscan No matching physical volumes found Additional information: Using md5sum, I confirmed that both pvcreate and vgcreate modify the file and that it is unmodified (compared to post-vgcreate) after a reboot.
Thanks for reporting this. Peter is investigating.
Well, that's a regression caused by some changes in /lib/udev/rules.d/69-dm-lvmetad.rules that appeared in lvm2 v2.02.99 and it was backported to F19 as an extra patch. The fix is now upstream, it will appear in next lvm2 F19 update: https://git.fedorahosted.org/cgit/lvm2.git/commit/?id=cac49725c9a2a1f5c0e48235a07f168d98458ace
Workaround is probably to run: pvscan --cache /dev/loop1
Thanks for the quick confirmation and fix. Also, the workaround does the job, thanks!
lvm2-2.02.98-12.fc19 has been submitted as an update for Fedora 19. https://admin.fedoraproject.org/updates/lvm2-2.02.98-12.fc19
Package lvm2-2.02.98-12.fc19: * should fix your issue, * was pushed to the Fedora 19 testing repository, * should be available at your local mirror within two days. Update it with: # su -c 'yum update --enablerepo=updates-testing lvm2-2.02.98-12.fc19' as soon as you are able to. Please go to the following url: https://admin.fedoraproject.org/updates/FEDORA-2013-15098/lvm2-2.02.98-12.fc19 then log in and leave karma (feedback).
lvm2-2.02.98-12.fc19 has been pushed to the Fedora 19 stable repository. If problems still persist, please make note of it in this bug report.