Description of problem: I have two mirrored disks. On the mirror I have created a logical volume /dev/VolGroup00/LogVol00 which contains the root filesystem. Initially I made the volume 4GB. Later I needed more space, so I decided to extend the volume to 8GB. I booted from the FC5 rescue CD and ran the following commands: dmraid -a y lvm vgscan lvm vgchange -a y lvm lvextend -L +4G /dev/VolGroup00/LogVol00 fsck /dev/VolGroup00/LogVol00 resize2fs /dev/VolGroup00/LogVol00 Then I rebooted the system from disk and got the following error from fsck: Checking filesystems /dev/VolGroup00/LogVol00: The filesystem size (according to the superblock) is 2097152 blocks The physical size of the device is 1048576 blocks Either the superblock or the partition table is likely to be corrupt! /dev/VolGroup/LogVol00: UNEXPECTED INCONSISTENCY, run fsck manually. I entered the system administration mode and checked the size of /dev/VolGroup/LogVol00 with "lvm lvs": 4.00G I booted with the rescue CD again and checked the size the volume's size: 8.00G. It seems that when I boot the system normally it doesn't "see" that the size of the logical volume has changed. Now I'm stuck because I can't boot the machine, and I don't know how to fix the problem. No-one responded when I asked the linux-lvm list. Version-Release number of selected component (if applicable): How reproducible: Steps to Reproduce: 1. 2. 3. Actual results: Expected results: Additional info:
Could you please give lvm version info from the rescue CD you are using as well as from the installed distribution? Output of pvscan -vvvv and vgscan -vvvv from both would be nice, plus full output of lvs and pvs. Thanks.
I eventually managed to fix the problem, and now the machine is upgraded to FC6. At the the time however, I was using the original FC5 rescue disk, and the FC5 installation was up-to-date using yum. Anyway, I think that the problem was because the meta-data on the hd was not being updated properly. What finally fixed the problem was (I believe) that I booted using the rescue disk, then did a vgcfgrestore to write correct meta-data to the hd. When I booted from the hd next time fsck was happy and saw the correct lvm device size. See http://www.redhat.com/archives/linux-lvm/2007-February/msg00026.html
Fedora apologizes that these issues have not been resolved yet. We're sorry it's taken so long for your bug to be properly triaged and acted on. We appreciate the time you took to report this issue and want to make sure no important bugs slip through the cracks. If you're currently running a version of Fedora Core between 1 and 6, please note that Fedora no longer maintains these releases. We strongly encourage you to upgrade to a current Fedora release. In order to refocus our efforts as a project we are flagging all of the open bugs for releases which are no longer maintained and closing them. http://fedoraproject.org/wiki/LifeCycle/EOL If this bug is still open against Fedora Core 1 through 6, thirty days from now, it will be closed 'WONTFIX'. If you can reporduce this bug in the latest Fedora version, please change to the respective version. If you are unable to do this, please add a comment to this bug requesting the change. Thanks for your help, and we apologize again that we haven't handled these issues to this point. The process we are following is outlined here: http://fedoraproject.org/wiki/BugZappers/F9CleanUp We will be following the process here: http://fedoraproject.org/wiki/BugZappers/HouseKeeping to ensure this doesn't happen again. And if you'd like to join the bug triage team to help make things better, check out http://fedoraproject.org/wiki/BugZappers
This bug is open for a Fedora version that is no longer maintained and will not be fixed by Fedora. Therefore we are closing this bug. If you can reproduce this bug against a currently maintained version of Fedora please feel free to reopen thus bug against that version. Thank you for reporting this bug and we are sorry it could not be fixed.