This content has been marked as final. Show 18 replies
When I boot the system normally I get the following messages...
Buffer I/0 error on device dm-0, logical block 0 (this repeats several times for other logical blocks)
INIT: version 2.85 booting
Your system appears to have shut down uncleanly
Checking root filesystem
fsck.ext3 Could this be a zero-length partition?
: Attempt to read block from filesystem resulted in short read while trying to open /dev/VolGroup00/LogVol00
Give root password for maintenance
(or type Control-D to continue): _
If I boot from a Rescue CD, and select the option to 'Find Linux Installation and mount' it finds the Root Volume Group and mounts it under /mnt/sysimage. I can see the files are still present, but the filesystem mounts as readonly.
I've just tried a dmesg in Rescue Mode and noted the following...
EXT3-fs error (device dm-0): ext3_journal_start_sb: Detected aborted journal.
Remounting filesystem readonly
I'm not sure what dm-0 is?
dm-0 is the device mapper's first mapping.
LVM works using the device mapper (remember I said that /dev/VolGroup00/LogVol00 probably is a symbolic link? the symbolic link points to /dev/mapper/VolGroup00-LogVol00 if I am not mistaking).
I am checking this on RHEL5, and see the separate device mapper devices are not there anymore. (mmh, I really need a RHEL4 image in my vmware again)
do a long listing (ls -ls) of /dev/VolGroup00/LogVol00 and you'll see. (post output!)
is dm-0 situated on the SAN slice which was pulled?
are you 100% sure the SAN slice isn't readonly to the system? if so, you can't fsck (quite obviously)!
how did you made certain the SAN slice is read-write accessible?
1. what we need to know is what causes the message "Buffer I/0 error on device dm-0, logical block 0 (this repeats several times for other logical blocks)". is it LVM or the filesystem?
2. the message "EXT3-fs error (device dm-0): ext3_journal_start_sb: Detected aborted journal. Remounting filesystem readonly" means the rescue cd mounts the filesystem (!!!!!) unmount the filesystem ('umount') and fsck it until it does not give any error. Do that as ext2 (no journalling). After that, reset the journal with the command I've supplied previously.
after that, you should be able to mount the filesystem read/write. if so, retry to boot the system normally.
The SAN disk was Read-Only - I didn't think that would be the case, but then I didn't think two days ago that they'd pull the SAN disk from an active server either!
The VM System Image was in a LV on the VM Host - After you mentioned checking to make sure it wasn't read-only I did some tests on it. Once that was rectified I restarted the VM and the fsck commands you'd given previously fixed the problems without issue.
Thanks for your help and patience!,
Please take a little time to make sure nothing is corrupted!
As I've posted earlier in this thread, only the metadata is journalled with default mounted filesystems.
In case of an oracle database, dbverify the entire database.
For operating system files you've done the test available already: fsck.