anobo@gmx.de:
>
> During a dist upgrade, my /var went full and I started to do the
> following with the lvm commands: reduce /home to 100G,
You need to remember that LVM is just a logical layer between your
disks/partitions and the filesystem. If you shrink an LV, you break the
filesystem using this LV. What you should have done is resize2fs your
/home first.
> increase /var by +5G,
> increase /usr by +6G, and
> increase /root by 600M.
>
> After that the whole thing went mad.
This is expected. :->
Did you actually run resize2fs after running lvresize for these LVs? If
you didn't, you didn't actually gain space on these filesystems and that
might make it possible to revert to the old layout.
> During boot it stops during fsck for /home with error 4 ("filesystem
> (according to superblock) is 36210688 blocks The physical size of the
> device is 26249216" and "superblock or partition table is corrupt").
That's fsck telling you that you shrinked the LV without shrinking the
filesystem first.
> My idea is to use the partition table to "fix" the lvm (i. e. return
> to the initial state). Is this possible and how to do it?
This is probably only feasible if you didn't actually resize your other
filesystems (/var etc.). You would need to lvresize these filesystems
back to their original size first and then grow /home using lvresize.
You might be lucky enough to have old size information available in
/etc/lvm/backup.
If you actually resized your other filesystems after shrinking /home's
LV, you may still try the procedure above, but of course you need to
revert the resize2fs operation in advance. And that will probably result
in a more or less severely damaged filesystem.
Backups help. :)
J.
--
At night I go to the kitchen; specifically, the knife drawer.
[Agree] [Disagree]
<http://www.slowlydownward.com/NODATA/data_enter2.html>
Attachment:
signature.asc
Description: Digital signature