[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]

[linux-lvm] superblock or partition table corrupt - fixable?



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


[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]