Josh-Daniel S. Davis (joshdavis) wrote,
Josh-Daniel S. Davis


Well, crap... I couldn't salvage /storage from the woes of linux LVM.

I started with kernel-image-2.4.18-bf2.4 and I believe lvm10, both from stable.
lvm-mod.o is 1.0.1 and lvm10 is 1.0.4 and lvm-common is 1.5.5
I built a volume group (datavg) from /dev/hdc3, which was most of a 120g drive.
PE size 32, LV and PV max was 15 or 16 (I was playing)
Built ext3 filesystem on /dev/datavg/stg01, mounted on /storage
I moved the contents of old /storage (/mnt, reiserFS on /dev/hdb3) to /storage
I unmounted, changed the partition type, and pvcreated /dev/hdb3
I vgextended onto this and used e2fsadmin to grow the filesystem to all byt 50 PEs.

At this point, all was excellent.
At some point I went to testing to resove some issues installing zoph and php4 (ended up purge/reinst to correct those).

Things were still fine, even after reboots, and, uh, toddler-finding-reset-switch.

So I get gigabit r8169 cards, and the kernel module doesn't compile.
So I grab kernel-image 2.4.20-1-686, being the latest available debian package.
Had some trouble here, because it expects devfs, but nothing serious.
Except I couldn't mount /storage anymore.

pvdisplay showed
VG Access read/write
VG Status NOT available/resizable

vgscan didn't find the vg, so it was removed from lvmtab and /proc/lvm, but it's there.

pvscan showed it was there, but it was not available, on each volume

I tried, and got:
vgcfgrestore -- you may not have an actual backup of restored volume group

I STFW and found procs by HM for similar problems... aparently, pvcreate, first, then vgcfgrestore. I did this, and no dice. Same problem.

So I saw stuff where vgcfgrestore had problems and broke things if the PVs were listed in reverse order, and the fix was in newer code, maybe 1.0.5? (forgetting).

So I did apt-get update and apt-get install lvm10.

I get lvm 1.0.7. I didn't realize until later, but the 2.4.20 kernel has lvm-mod 1.0.5.
So I try the vgcfgrestore again, same problem.
So I try pvcreate and vgcfgrestore, and now it says the size is wrong.
So I searched on THIS and it says that the structures change b/t versions, and it's go back to the old version, or lose your data.
So I go back to the old module and tools, still says size problem.
I tried recreating my VG and LV in the same order as before, and I can't even find the superblocks.

So I figure I'll go to sistina and see if I can get the 1.0.7 kernel mod and compile it.
Their ftp server is down and has been all weekend.

I haven't been able to find any tools to convert the vgda backups, nor anything further other than "your data is gone" from other people's similar experiences.

But, my data is there. It's hiding. Damnit. Anyone have any suggestions/resources for this?

So I rebuilt the array in the PROPER order, and I still can't find the superblock, and still cant' fsck it, but this time e2salvage is finding inodes. We'll see if it can fix it.

I think it will eat the filesystem because everything will be offset by whatever the NEW VGDA size is rather than the old VGDA size. Maybe it's smarter than that, but I doubt it. I'm tired of fucking with it. I have most of my really important data, and I can get some of the rest from friends and such. I'm going to stick to ext2 on partitions until I can afford an AIX box with a pair of 148g SCSI drives to run AIX LVM on.
Tags: evil, linux
  • Post a new comment


    Anonymous comments are disabled in this journal

    default userpic

    Your reply will be screened

    Your IP address will be recorded