I feel awful...

I was trying to install picasa, but my /opt wasn't large enough. There was no logical volume for it like most of my other partitions (default debian etch lvm non-encrypted scheme w/ home, var, and others on lvm).

First I did
to reduce the var by 500 megs since it was not using anywhere near that much.

Next I did

to make a logical volume for opt.

After that I put
in /etc/fstab to follow the forms of the similar lvm entries.

So now I can boot, but everything's borked. I can ping google, for instance, but I can't use apt-get install. X11 won't start up, but I can use vim. If I comment out the line for opt in fstab, it still doesn't work. I noticed a lot of errors at boot about read-only directories, so I think my lvm's were mounted read-only. I'm pretty ignorant about this obviously...

Also, at boot, when it tries to do fsck.ext3 on var, it fails. I think /var is the only thing that ends up being read-only during boot. Of course this botches a lot of things since syslog hangs and other things don't work. But all the data seems to be there just fine, I just don't know how to get my system back to where it was.

Is there anything I can do?

did you resize2fs /var?

More importantly, did you resize the filesystem first ... as in *first* ???.
Setting the lv back to the original size might work, but you'll always be worried something was written over.

I'm unclear on what you mean by first, but I have already been using this comp w/ debian for a few months. Important stuff is backed up.

So yes, the /var was in use by syslog and anything else that needs /var when I reduced the size. I thought I could reduce the size safely since it was 1.5G and I reduced it to 1G. Not even half was used, so I thought it was safe to reduce it by 500M.

Booting looks fine until it gets to the logical volumes. As it does an fsck, everything clears until it gets to /var and the specific error it gives is:then it says to repair the filesystem manually. /var is read-only, but I haven't checked to see whether the data is intact or not.

Should I try to resize var back to what it was? /opt doesn't seem to show up as an lv at all, but should I just retrace my steps as I listed them above in this post?

Thanks for the help!

I tried retracing my steps by doing:
but I got an even scarier error showing numbers to the effect that the size of the var partition is bigger than it actually is, and that the partition tables may be corrupt etc.

I just reduced the size back to 1G and it is now back to the crippled, but bootable state. When it finally boots, all my files in var look fine, but it still mounts read-only and botches the system.

I am still waiting for help--thanks to anyone who can help me.

Someone in irc was helping me with this problem, and now I understand that I needed to make the filesystem smaller before I reduced the logical volume. Supposedly it's like deciding to shorten your bed by 3 feet, but missing the crucial idea that if you are in the bed, you should move your legs back 3 feet before chopping the bed down--otherwise you lose your legs. Here I chopped off the filesystem holding /var.

I also learned a bit about vgcfgrestore, but unfortunately, I still get this message when I try to fsck /dev/mapper/<vgname>-var:

"unable to set superblock flags on /dev/mapper/<vgname>-var"

Is this a lost cause?

JACKPOT!!! I finally got it working. This ubuntu link gave me the final clue I needed.

My problem was that I needed to get the logical volume holding var back to its original size before I could fsck and get it where the system would not mount it read-only (and be able to find all the old data).

So in short,eventually did the trick. I say "eventually" because it still complained about the size not matching I was very fortunate because the logical volume with var had initially taken the full room of whatever I reduced in the volume group. I just had to keep doing extend -L+500M /dev/mapper/<vgname>-var until it complained of not having anymore space, but I still had to squeeze in a bit here and there.

I don't know what I would have done if the logical volume had been of some size that had become indeterminate after messing with it...