On Tue, 2006-04-11 at 09:45 +0100, William Murray wrote: > On Tue, 2006-04-11 at 09:25 +0100, William Murray wrote: > > On Mon, 2006-04-10 at 07:26 -0400, fedora-list-request@xxxxxxxxxx wrote: > > > Another possibility might be to try converting your LVM2 volume group > > > to > > > LVM1 using vgconvert in FC5. > > > > > > Paul. > > > > > Paul, you are really helpful. But I got myself into more knots. > > vgconvert said: > > lv_number -19205086645 too large > > ... > > Use pvcreate and vgcfgrestore to repair from archived metadata > > > > But now vgdisplay, vgconvert, vgscan, pvscan all give 'segmentation > > fault' and the disk claims to be uninitialised for the graphical lvm > > client. > > Do you think there is a way to recover this? > > Sorry, > > Bill > I guess I was being stupid - I tried this with the filesystem mounted. > Anyway, the file-system is still mounted, and I think my best bet is > to save the bits I want (its interesting how despite a backup there are > still bits I want) and start over. I guess you learned the hard way why you should NEVER do filesystem operations that will modify the filesystem or partition data on a running system. LVM, fsck, and fdisk are all tools that come to mind quickly (among others) that have a possibility to destroy your data if used improperly Note, some parts of the lvm tools can be used if done correctly, but it is safer to not do so. What happens with those types of tools is the kernel knows the config at boot time, but does not get told of the changes until the next reboot. It can easily wipe out an entire drives worth of data.