This content has been marked as final. Show 18 replies
There are two types of errors here:
- filesystem errors
- LVM errors
First you need to repair LVM, because LVM gives access to the logical volume in which the filesystem is present.
- boot from a livecd like the rescue mode from the o/s cd or knoppix.
Is LVM giving errors when doing a pvscan?
- after LVM is fixed, fsck the filesystem in the logical volume
Is the filesystem still corrupt?
Once both are checked and resolved, boot again with the system itself.
If the errors persists after fixing all with a boot cd, please post extensive errormessages.
Bit of an update...
In Rescue Mode (I've skipped mounting my disks) - I've run a vgscan and a vgchange -ay. All Logical Volumes were found.
When I try to do an e2fsck of /dev/VolGroup00/LogVol00 I get the following...
# e2fsck /dev/VolGroup00/LogVol00
ext3 recovery flag clear, but journal has data
Recovery flag not set in backup superblock, so running journal anyway.
/dev/VolGroup00/LogVol00: recovering journal
ext3 recovery flag clear, but journal has data
REcovery flag not set in backup superblock, so running journal anyway.
e2fsck: unable to set superblock flags on /dev/VolGroup00/LogVol00
Okay, my assumption now is the LVM errors are resolved. (correct?)
Now let's try to resolve the filesystem errors:
-Boot without using the on-disk filesystems (bootcd or something else)
it's possible you need to run it several times.
fsck −t ext2 −fC −y /dev/VolGroup00/LogVol00
Please mind it's checked as ext2 (non journalling) instead of ext3
-If it is free of errors, recreate the journal with:
tune2fs −j /dev/VolGroup00/LogVol00
Please mind any corruptions inside the filesystem can occur. You should check that in two stages:
All operating system tools use normal, buffered IO. (that I am aware of, please correct me if somebody has seen something different)
This means that any file modifications (user-imposed, thus modified configuration files, and system imposed, like installing binaries) are done in memory, and eventually flushed to disk (by a process called 'pdflush'). When a disk is pulled, there is a chance not all modifications are already flushed to disk, thus will be corrupt.
This is the same for the oracle database files, with the exception of databases using DIO, direct IO. Direct IO is enabled if the database parameter 'filesystemio_options' is set to 'direct' or 'setall'. Direct IO bypasses the operating system buffercache and does IO (reading and writing) directly from the blockdevice, instead of asking the operating system for the block in normal mode, which caches the requested block(s) in the operating system/linux buffercache.
That is why normal/cached IO also is said to do 'double buffering', because there are two cache's ('buffers') involved.
-Okay, but it's journalled, isn't it?
But it depends on the type of journalling. Journalling might not be what you expect it to be.
Most filesystems, including NTFS and default ext3, only journal metadata transactions. Metadata transactions mean that only changes to the structure of the filesystem are journalled, not data-transactions.
Please mind that it is possible for ext3 to journal all modifications instead of only meta-data with the 'data=journal' mount option.
Yes, LVM seems to be fine...
When I try to issue the 'fsck -t ext2 -fC -y /dev/VolGroup00/LogVol00 command I get the following...
WARNING: couldn't open /etc/fstab: No such file or directory
/dev/VolGroup00/LogVol00: recoverying journal
fsck.ext2: unable to set superblock flags on /dev/VolGroup00/LogVol00
So it appears to still be treating it as an ext3 filesystem?
Thanks for your help so far!
Just to be certain: are you root?
What are the rights set on the logical volume (if I recall correctly /dev/volumegroup/logicalvolume is a link, we need the rights on the device itself)?
This message could indicate the slice is presented readonly to the machine.
A quick test should be able to proof this.
PLEASE MIND THIS IS DANGEROUS!
This copy the first 1 kilobyte of the logical volume to a file called 'tt' in /tmp:
And copy it back:
dd if=/dev/VolGroup00/LogVol00 of=/tmp/tt bs=1k count=1
And see if this yields any errors.
dd if=/tmp/tt of=/dev/VolGroup00/LogVol00 bs=1k count=1
Tried that but no joy, I'm still getting the superblock errors. The annoying thing is, if I restart in rescue mode and ask it to search and mount the filesystems it does without error and I can see and browse the files.
Is it possible to 'rebuild' a filesystem or to change parameters to force it to mount?
Can you elaborate way more?
What do you do exactly when all goes well, and what do you do exactly when it goes wrong?
You need to take into account we cannot look into your system, and know what messages are appearing. All this information is needed in order to help you.
Yes, it is possible to change things inside the filesystem, but you need to make the picture complete.
Provide all information about when you are able to mount the filesystem, and similar information about when you get errors.