My problem is that system-config-lvm seems to have corrupted the
superblock on my root logical volume. When I boot I am required to fsck
manually and this reports: "Either the superblock or the partition table
is likely to be corupted." Further details show that the superblock
thinks the volume size is some 71663616 blocks where as the physical
size of the volume is just 57884672 blocks. The following is a
description of how I got to this point.
I have a Fedora 7 box, recently upgraded from FC5. System had a single
250GB HD and I am in the process of adding a second HD, this time 500GB.
I used system-config-lvm to create a partition on the new drive and
added it to the original volume group (VolGroup00).
I then attempted to extend the original logical volume (LogVol00) by
some arbitrary portion of the newly added PV - I kind of assumed that
part of the point of LVM was to allow LVs greater in size than a PV. I
still don't know whether or not this is supported, but in any case the
operation in system-config-lvm failed. I just assumed that this was a
graceful failure and went on to create a couple of new LVs for stuff I
would pull out of LogVol00.
I completed the configuration of the new LVs, including copying the data
from LogVol00 and updating fstab to mount the new LVs, but upon reboot I
am required to run fsck manually and the above listed error is produced.
So it seems to me that my original attempt to expand LogVol00 using
system-config-lvm did not actually fail gracefully - it appears to have
updated the superblock with the new size before then falling over when
updating the partition table.
fsck is not particularly helpful - upon boot the system stops and
requires me to run fsck manually with no -p. The first error that comes
up when I manually fsck is the one listed above followed by an Abort
prompt which requires a N response in order to continue (so there goes
any opportunity of using -y). If I don't abort it goes onto Phase 1,
checking inodes, blocks and sizes and starts failing on blocks above
57884672. Each block then fails, so something like 41 million Y
responses would need to be manually entered in order to get through
Phase 1 of fsck - not really viable and unlikely to resolve the problem
in any case.
If I boot using the Fedora 7 DVD and select the recover mode it mounts
the volume group with no problem and all of the data is present and
accessible (in fact the entire system image seems fine, including the
data on the two new LVs I created).
To me this says that all is well, but this doesn't stop fsck from
falling over when it hits the bad information in the superblock.
I have looked at the set up using TestDisk, but since it doesn't look
inside the LV it doesn't seem to offer much hope.
I am guessing that the solution would be to somehow revert the volume
size in the superblock. Is there some way to do this or am I barking up
the wrong tree?
TIA for any assistance rendered,
Scott
_______________________________________________
linux-lvm mailing list
linux-lvm@redhat.com
https://www.redhat.com/mailman/listinfo/linux-lvm
read the LVM HOW-TO at http://tldp.org/HOWTO/LVM-HOWTO/
