Linux - SoftwareThis forum is for Software issues.
Having a problem installing a new program? Want to know which application is best for the job? Post your question in this forum.
Notices
Welcome to LinuxQuestions.org, a friendly and active Linux Community.
You are currently viewing LQ as a guest. By joining our community you will have the ability to post topics, receive our newsletter, use the advanced search, subscribe to threads and access many other special features. Registration is quick, simple and absolutely free. Join our community today!
Note that registered members see fewer ads, and ContentLink is completely disabled once you log in.
If you have any problems with the registration process or your account login, please contact us. If you need to reset your password, click here.
Having a problem logging in? Please visit this page to clear all LQ-related cookies.
Get a virtual cloud desktop with the Linux distro that you want in less than five minutes with Shells! With over 10 pre-installed distros to choose from, the worry-free installation life is here! Whether you are a digital nomad or just looking for flexibility, Shells can put your Linux machine on the device that you want to use.
Exclusive for LQ members, get up to 45% off per month. Click here for more info.
I have an idea but not sure about the success rate. Instead of running e2fsck to reconstruct the superblock using backup superblock why can't we try mounting LV with backup superblock?
Basically this is what you have to do, perform pvcreate, vgcfgrestore and vgchange as you did yesterday. To find the superblock run dumpe2fs:
Code:
dumpe2fs /dev/mapper/VolGroup00-LogVol02 | less
scroll down where it shows backup superblock.
Now try mounting it as follows:
Code:
mount -t ext3 -sb <backup-superblock> /dev/mapper/VolGroup00-LogVol02 /newdisk
I thought it is worth giving a try before you run e2fsck on the disk.
Note: You will have multiple backup superblock try couple of them and see if you get any result
Unfortunately, dumpe2fs will fail because the primary super block is missing, but testdisk will report the backup super block locations if you run the "Advanced" (Filesystem utils) action and then select "Superblock". That number will be in filesystem blocksize units, so it needs to be multiplied by 4 (typically) to convert to the 1K block size units needed by the mount command.
I just gave that a try, but could not mount the filesystem if the root directory was overwritten.
Yes you are right. What about mke2fs -n, that will give an idea where backup superblocks are. This is something which has to be tried with caution, if command mke2fs run without -n switch it will end up formatting the partition.
I even tried mkfs.ext3 with the "-S" and "-b 4096" options to rewrite the super blocks and group descriptors, and I still didn't get a filesystem that I could mount. It makes sense. The kernel can't do much with a filesystem that lacks its root directory. The only way I got anything recoverable was by letting fsck.ext3 "do its thing".
I also went through all backup super blocks recommended by mke2fs -n with e2fsck -n -b, but all checks reported just
e2fsck: Bad magic number in super-block while trying to open /dev/mapper/VolGroup00-LogVol02
The superblock could not be read or does not describe a correct ext2
filesystem. If the device is valid and it really contains an ext2
filesystem (and not swap or ufs or something else), then the superblock
is corrupt, and you might try running e2fsck with an alternate superblock:
e2fsck -b 8193 <device>
That looks like the result you get if you choose the "Analyze" (Analyse current partition structure ...) function rather than the "Advanced" (Filesystem Utils) function. Filesystem Utils should be essentially instantaneous in detecting the ext3 filesystem.
I also went through all backup super blocks recommended by mke2fs -n with e2fsck -n -b, but all checks reported just
e2fsck: Bad magic number in super-block while trying to open /dev/mapper/VolGroup00-LogVol02
Did you multiply those numbers by 4? mke2fs reports in fs block size units (typically 4K). The mount command wants 1K block size.
[EDIT] Oops, sorry. You were talking about e2fsck, not mount. Really, e2fsck should find the backup super blocks on its own.
Last edited by rknichols; 05-04-2015 at 05:19 PM.
Reason: Oops
That's about where I am, too. Something other than the simple removal of the LVM structure went on. What's left doesn't seem recoverable. Sorry things didn't work out better.
LinuxQuestions.org is looking for people interested in writing
Editorials, Articles, Reviews, and more. If you'd like to contribute
content, let us know.