[linux-lvm] 0.9.1 vgscan doesn't detect upgraded vg's
dmeyer at dmeyer.net
dmeyer at dmeyer.net
Tue Feb 6 08:22:56 UTC 2001
In article <200102060630.f166UYM32021 at webber.adilger.net> you write:
> Michael McLinn writes:
> > My theory is each pv is supposed to have the the UUID's of
> > itself, and all other pv's in it's vg within it's UUID
> > datastructure. Is this so?
>
> Correct. There was another user who reported the same bug, but after
> they were playing with the system a bit, it started to work (i.e. the
> UUIDs were filled in) so it was not looked at further.
That other user was me. I eventually commented out the UUID check in
pv_read_all_pv_of_vg as the previous poster suggested. This let me
run vgscan, vgchange -ay, and mount my LVs. Just go to
pv_read_all_pv_of_vg.c and get rid of the code after the
if ( uuids > 0 ) {
check.
> > If this is the case, it seems it would be possible to write the
> > correct UUID's to the datastructure on disk, and potentially
> > improve (maybe even fix) my situation.
After getting vgscan to find my VGs, I pretty much just lucked into my
UUIDs getting set correctly and I'm still not sure what did it. All I
did was activate my VGs (which I'm told couldn't have fixed the
UUIDs), run vgck (ditto), and run vgscan after the VGs were active.
vgscan at least _calls_ pv_write_uuidlist, so it is a possibility.
However, running vgscan on the non-active VGs definitely didn't update
the UUIDs for me.
> > One more note that might be of interest, these volume groups were
> > created with a much earlier version of lvm, 0.6 or 0.7 I believe.
>
> I don't know what the situation was with the other person who had
> this same bug, but it is good to know anyways.
Mine were originally created with 0.8final.
--
Dave Meyer
dmeyer at dmeyer.net
More information about the linux-lvm
mailing list