On Fri, 2006-04-14 at 20:27 +0200, Nicolas Mailhot wrote: > For those interested the procedure was to install / on an lvm, then try > to move the lvm to a pvm (on another raid volume in my case, don't know > if it's important) Errr. Do you mean moving an LV to another PV? As in using pvmove? I had rather serious system eating (but ultimately recoverable) problems with pvmove when I moved my system to LVM using an FC5 rescue disk. It may not just be system-config-lvm. For no reason I could figure out, about half the time pvmove would crash and totally eat the PV metadata. This happened several times. Trying to do anything would just result in messages such as: Incorrect metadata area header checksum Inconsistent metadata copies found - updating to use version 8 Automatic metadata correction failed A full verbose log: http://fedora.pastebin.com/634358 (Note, piping the log to a file seemed to have messed up the order a bit from how it appears on screen) The trick to recovering: 1) Back up the VG metadata 2) Rewrite the PV metadata on *every* pv like so: http://www.tldp.org/HOWTO/LVM-HOWTO/recovermetadata.html You will be told you have to use -ff. Do it. 3) You will now find your VG is completely gone. Don't panic, restore the backup. Your VG should be back now. My googling couldn't find anyone with quite the same problem. The best I could find was "Back up the metadata then restore", which wasn't quite enough here. As usual I'm slacking about bugzilla-ing. I wanted to be more sure about what was causing it to mess up, but that hasn't happened. Its entirely random near as I can tell.
Description: This is a digitally signed message part