vgchange bug?
Before I raise a Bugzilla report for this, is this a known problem? I have
some mods to my F17 system so I¹m not sure if it¹s part of the base or not:
When trying to bring up some LVM volumes in R/O mode we were not always
getting our LVM volumes discovered. On boot, sometimes it would find one
other times none:
Setting up Logical Volume Management:
1 logical volume(s) in volume group "v-b0545f6c-2223-4033-bb4e-fba28ba18994"
now active
[ OK ]
Yes, when we're up vgscan finds all three...
[root@SMALL ~]# vgscan
Reading all physical volumes. This may take a while...
Found volume group "v-db5d4905-33e3-4ba2-baf0-4d1db9845971" using metadata
type lvm2
Found volume group "v-ec99e989-d738-44a4-a2d9-9d7171c5ebd4" using metadata
type lvm2
Found volume group "v-b0545f6c-2223-4033-bb4e-fba28ba18994" using metadata
type lvm2
But only one is seen in /dev:
ll /dev/v-*/vol
lrwxrwxrwx 1 root root 7 Aug 21 09:46
/dev/v-b0545f6c-2223-4033-bb4e-fba28ba18994/vol -> ../dm-0
I have found that this was caused by an existing /etc/lvm/cache/.cache on a
filesystem that was RO during sysinit. If I erase the cache, then it works
without any problems. The reason why that file is there is that we are
cloning instances.
At this point, we have a workaround. We also think this is a bug, if the fs
is readonly and the --sysinit flag is on, it shouldn't rely on an old cache
on a read only FS.