Fedora Linux Support Community & Resources Center
  #1  
Old 6th August 2007, 02:03 AM
seade Offline
Registered User
 
Join Date: Aug 2007
Posts: 11
Unhappy [resolved] superblock or partition table corrupt

I've haven't been able to find any references to this problem in the forums or elsewhere.

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 crrupted." 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.

To my way of thinking 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,

Scott

Last edited by seade; 7th August 2007 at 06:11 AM. Reason: Added [resolved] to title
Reply With Quote
  #2  
Old 6th August 2007, 02:13 AM
Figment Offline
Registered User
 
Join Date: Jan 2007
Location: New York City
Posts: 109
Is there data on the new hard drive that you need? I would suggest using gparted to repartition the disk and start over. If you can't boot fedora, use the gparted livecd. I don't know if you need a less brute-force solution than this, though.
__________________
I am a figment of my own imagination.
Smolt Profile
Reply With Quote
  #3  
Old 6th August 2007, 02:27 AM
seade Offline
Registered User
 
Join Date: Aug 2007
Posts: 11
Quote:
Originally Posted by Figment
Is there data on the new hard drive that you need? I would suggest using gparted to repartition the disk and start over. If you can't boot fedora, use the gparted livecd. I don't know if you need a less brute-force solution than this, though.
Blindingly fast reply - thanks!

Yes the new drive does now have data on it - among other things a full copy of /home which may come in handy given the problems I am currently experiencing.

From what I can tell gparted does not support LVM - I suspect this may be a show stopper.

Scott
Reply With Quote
  #4  
Old 6th August 2007, 02:58 AM
Figment Offline
Registered User
 
Join Date: Jan 2007
Location: New York City
Posts: 109
What is the physical layout of the disk? And what logical volumes do you have set up now? I don't use LVM myself so I don't know much about it. I think you're right about gparted, though. However, the logical volumes have to exist on a physical partition (or so I thought) so you may have to fix the partition table for the disk. How to do that without losing data I'm not sure.
__________________
I am a figment of my own imagination.
Smolt Profile
Reply With Quote
  #5  
Old 6th August 2007, 03:56 AM
seade Offline
Registered User
 
Join Date: Aug 2007
Posts: 11
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.

Searching for answers it appears that TestDisk may be of assistance. I am in the process of downloading Parted Magic so that I can give this a shot.

Scott
Reply With Quote
  #6  
Old 6th August 2007, 06:12 AM
seade Offline
Registered User
 
Join Date: Aug 2007
Posts: 11
Hmm. TestDisk didn't help so I am stuck again!
Reply With Quote
  #7  
Old 6th August 2007, 08:25 AM
seade Offline
Registered User
 
Join Date: Aug 2007
Posts: 11
So I am thinking that the answer will be to do something like
Code:
resize2fs /dev/VolGroup00/LogVol00
but to do this I need to boot with the rescue CD and unmount /mnt/sysimage.
Would you believe I cannot
Code:
umount /mnt/sysimage
- it says "Device or resource busy" and when I
Code:
fuser /mnt/sysimage
it crashes with a segmentation error.

This is really frustrating - everything I try is failing and yet my data is all there and completely accessible.

Scott
Reply With Quote
  #8  
Old 6th August 2007, 09:30 AM
mnisay Offline
Registered User
 
Join Date: May 2005
Location: PH
Posts: 696
Try to boot again with linux rescue and DO NOT mount any partition when prompted even as READ-ONLY.

then do umount / fuser thing .

Could you post the output of

# ls -la /sbin/lvm.static

...just want to check yours.
Reply With Quote
  #9  
Old 6th August 2007, 03:20 PM
seade Offline
Registered User
 
Join Date: Aug 2007
Posts: 11
Quote:
Originally Posted by mnisay
Try to boot again with linux rescue and DO NOT mount any partition when prompted even as READ-ONLY.

then do umount / fuser thing .

Could you post the output of

# ls -la /sbin/lvm.static

...just want to check yours.
Even though the filesystem is mounted read only, it still cannot be unmounted - it still complains "Device or resource busy".

fuser causes a segmentation fault.

lsof can only find itself open.

If I use df to view the available filesystems I can umount all but sysimage.

There is no /sbin/lvm.static file (though there is one in /mnt/sysimage/sbin (since I have been unable to umount it).

If I tell the rescue disk to skip mounting the system image so that I can do it manually using vgchange it doesn't load the necessary kernel extensions to support lvm!

Not very happy at present.

Scott
Reply With Quote
  #10  
Old 6th August 2007, 03:47 PM
seade Offline
Registered User
 
Join Date: Aug 2007
Posts: 11
Okay, I managed to get at the VolGroup device files via the rescue disk. Followed the instructions at http://samfw.blogspot.com/2005/12/lv...scue-mode.html - the difference was accessing the lvm commands via lvm rather than directly.

Do I then tried my "resize2fs /dev/VolGroup00/LogVol00" which of course suggested I do an e2fsck first - well I already know that isn't going to work!

resize2fs provides a -f flag to skip the safety checks - when I use this I get "resize2fs: Can't read an block bitmap while trying to resize /dev/VolGroup00/LogVol00". So now I am back to square one - everything is fine except the stupid superblock.

Scott
Reply With Quote
  #11  
Old 6th August 2007, 03:59 PM
larryt Offline
Registered User
 
Join Date: Jul 2007
Posts: 82
Hi all,

I believe that all file systems had many many alternate superblocks that are written to the disk as a backup to the prime, so that if the prime superblock is corrupt, you can tell fsck to use a alternate (if you know it).

I believe that the first alternate file system superblock is always written to block 32 in any file system.

I'm somewhat of a novice to Fedora myself, so Scott, before you follow my advice here, check with the other posters to see if this makes sense to them as a easy fix before you blindly follow my advice and I end up messing you up. But it could be as easy as a "fsck -b 32 <file system>.

Check the man page on fsck.

Hope that helps,

Larry
Reply With Quote
  #12  
Old 6th August 2007, 04:40 PM
mnisay Offline
Registered User
 
Join Date: May 2005
Location: PH
Posts: 696
ok , atleast you can come to manage them from lvm shell.

how about

# ls -la /mnt/sysimage/sbin/lvm.static

the reason why i am asking this is that all lvm mounting would fail during reboot if lvm-static is only 700 with the same superblock error, not sure why the same superblock. i fixed mine too by going to lvm shell and changing lvm.static from 700 to 755 i even tried other superblock numbers, but it didn't work.. one good thing about that is i managed to do a total backup wth 2 of my lvm partitions while in rescue mode.
Reply With Quote
  #13  
Old 6th August 2007, 11:59 PM
seade Offline
Registered User
 
Join Date: Aug 2007
Posts: 11
Quote:
Originally Posted by larryt
I believe that all file systems had many many alternate superblocks that are written to the disk as a backup to the prime, so that if the prime superblock is corrupt, you can tell fsck to use a alternate (if you know it).

I believe that the first alternate file system superblock is always written to block 32 in any file system.

I'm somewhat of a novice to Fedora myself, so Scott, before you follow my advice here, check with the other posters to see if this makes sense to them as a easy fix before you blindly follow my advice and I end up messing you up. But it could be as easy as a "fsck -b 32 <file system>.
Thanks Larry. Yes, I have tried alternative superblocks and they result in the same problem. It is not really that my superblocks are corrupted, it is just that system-config-lvm wrote to it before it's operation was completed. My understanding is that the LVM is supposed to support logical volumes that extend across more than one physical volume. First you add a physical volume to a volume group, then you ask it to expand an existing logical volume. To expand the existing logical volume it first extends the logical partition to the desired size, removing this amount of space from the free space in the volume group and then expands the file system on the logical volume to match the new size. When I asked system-config-lvm to expand the logical volume it did the first of these things, resulting in an update to the superblock, but then failed before it allocated the free space from the volume group and to extended the size of the file system. The update to the superblock must go through and update all the copies - i.e. the copies are there to protect against say a bad sector coinciding with a superblock rather than recovering from some arbitrary operation on a superblock.

This is quite a fundamental problem. The lvm is obviously a critical piece of underlying functionality. That it or one of the surrounding utilities has a bug in it that causes this type of problem is very surprising. Even more surprising is that there does not seem to be any tools available to address the resulting problem - I am left with a volume that is completely fine, but the bad information in the superblock cannot be repaired.

Thanks again for your suggestion.

Scott
Reply With Quote
  #14  
Old 7th August 2007, 12:15 AM
seade Offline
Registered User
 
Join Date: Aug 2007
Posts: 11
Quote:
Originally Posted by mnisay
ok , atleast you can come to manage them from lvm shell.

how about

# ls -la /mnt/sysimage/sbin/lvm.static

the reason why i am asking this is that all lvm mounting would fail during reboot if lvm-static is only 700 with the same superblock error, not sure why the same superblock. i fixed mine too by going to lvm shell and changing lvm.static from 700 to 755 i even tried other superblock numbers, but it didn't work.. one good thing about that is i managed to do a total backup wth 2 of my lvm partitions while in rescue mode.
The file is there and it actually has 555, but in fact I have no problems mounting the lvm volumes manually. The trouble is that fsck determines that the size of one particular logical volume is configured to be greater than the physical size of the device and hence cannot give the volume a clean bill of health and thus the boot process cannot proceed. The LVM obviously has to do some trickery with virtual devices and was only part way through doing this when the original error occurred. Since nothing actually crashed, all I saw was a reasonably benign looking error message, this is quite a nasty result.

Thanks anyway for your suggestion.

Scott
Reply With Quote
  #15  
Old 7th August 2007, 01:15 AM
shess01 Offline
Registered User
 
Join Date: Aug 2005
Location: On the road. What day is it again?
Posts: 253
OFF TOPIC: Why? Why God are logical volumes the default configuration in a Fedora install?!???!?? If you are running a system with multiple drives or RAID of some type sure, but why for the common user with a store bought system or a laptop??!?? LVM should *not* be the default install for anaconda....

I got 6 months of email, priceless pics of my daughter and some valuable work related documents sitting on a dead logical drive from my old laptop. My fault for not backing up, i know. But I have had drives crash before and, with a little help from the forums, recovered all of my files...

Jesus!!!! (waiting for a miracle...)

:end of rant.

Good luck dude, I will be watching this thread...
__________________
...What if there were no hypothetical questions?
Reply With Quote
Reply

Tags
corrupt, partition, superblock, table

Thread Tools Search this Thread
Search this Thread:

Advanced Search
Display Modes

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is On
HTML code is Off

Forum Jump

Similar Threads
Thread Thread Starter Forum Replies Last Post
Corrupt partition table? fearing data loss!! maxxum Using Fedora 4 16th July 2006 06:35 AM
XP Dual boot trouble CHS Partition table:Rebuilding Partition table ILovetux Using Fedora 0 15th May 2006 08:47 PM
Corrupt Superblock Halzor Hardware & Laptops 4 3rd June 2005 03:45 AM
Corrupt Partition Table? Uh oh... Bana Hardware & Laptops 5 25th March 2004 03:12 AM


Current GMT-time: 13:32 (Sunday, 21-12-2014)

TopSubscribe to XML RSS for all Threads in all ForumsFedoraForumDotOrg Archive
logo

All trademarks, and forum posts in this site are property of their respective owner(s).
FedoraForum.org is privately owned and is not directly sponsored by the Fedora Project or Red Hat, Inc.

Privacy Policy | Term of Use | Posting Guidelines | Archive | Contact Us | Founding Members

Powered by vBulletin Copyright 2000 - 2012, vBulletin Solutions, Inc.

FedoraForum is Powered by RedHat
...Dresdner Stallhof Travel Photos - Resort Giritirta Kahuripan - Kaliurang Travel Photos