partition missing in 2.1 AS

[Renjith Nair]

Iam facing a problem such that whenever my system reboots its giving me error that /dev/sdb1 is not a valid block. so i noticed in fdisk (parted also) that my /dev/sdb1 partition is missing. All other partitions have no problem and its only affecting this partition. Do anybody know how to recover from this issue. I tried scanning with gpart tool and made a partition without a filesystem on that specified area for /dev/sdb1. But its not working. Can anybody advice me,

thanks in advance

[Steven E. Protter]

Shalom,

You should first try and use fsck to fix the filesystem.

More likely you will need to use fdsk to rebuild the thing from scratch.

SEP

[Stuart Browne]

Ok, some quick questions.

What type of disk was /dev/sdb to begin with? Was it something in a SAN, or a RAID container, or just a plain SCSI disk?

Has there been any hardware funkies recently, like moving disks or arrays around?

Without knowing these, my first guess is that it's a SCSI disk that's had an ID changed, so it's presenting as a different device.

If nothing like htat has changed, then you might want to seeif the contents of the disk are still actually there (use 'dd if=/dev/sdb | cat -v - | less', and have a look around. You should get to the super-block/inode tables pretty early on if it hasn't been a disk failure). If the data is still there, then there are methods to recover data.

As a side note, how big is the disk? Just want to get a feel of the feasability of backing the entire disk up raw.

[Renjith Nair]

thanks for reply.

Iam having two RAID Arrays, /dev/sda in Raid1 and /dev/sdb in Raid5. Iam sure that its not a h/w failure. bcoz all the other partition in that raid is working very well. please tell me how to recover this data. It happened on march 18. Iam attaching the /var/log/messages file on that date. Please tell me

thanks

[Stuart Browne]

When you boot the server, does the RAID controller give you any warnings, and does it mention all of the containers correctly?

[Renjith Nair]

thanks for the reply

when i reboot the server the two arrays are getting properly detected. I don't think there is a problem in Hardware. Have u analyzed the messages file that i attached in last reply. From 18th march onwards this is missing

thanks

[Steven E. Protter]

The attachment did not attach.

Please submit, it will be very helpful.

Shmuel

[Renjith Nair]

pls find the attachment. The problem happened on 18 march

[Stuart Browne]

So the question is what happened to the RAID array before 18:28..

In the boot at 18:28:42, we see:

SCSI device sdb: 860149632 512-byte hdwr sectors (440397 MB)
sdb: sdb1 sdb2 < sdb5 sdb6 sdb7 sdb8 sdb9 sdb10 sdb11 sdb12 sdb13 sdb14 > sdb3

So at this point the partition at leaast existed. However, it is then followed by this at 18:28:43:

mount: /dev/sdb1 is not a valid block device

So even though it was there, it was aleady broken.

Later, at 22:23:00, it doesn't even see sdb1.

So what happened between 04:04:52, and 18:23:32 that caused the system to restart, and for a filesystem to become corrupted?

I don't suppose you've go the output of a 'file -s /dev/sdb1' before you started trying to re-make the file-system? Actually, what does it say now?

When you re-made the filesystem, what arguments did you give mkfs ?

[Renjith Nair]

thanks stuart

I haven't taken the output of file command. now its giving like this.

file -s /dev/sdb1
/dev/sdb1: MP32, Mono

I haven't made any filesystem on /dev/sdb1. I just created a partition using fdisk. Earlier that i had run gpart tool for scanning. But it didn't give any result. That day temperature in the server room was very high. when i came on monday the server was at power down state.

please advice

[Stuart Browne]

Ah, right. That could cause these sorts of corruptions.

MP32, Mono.. Weird. *looks up some magic*..

Right. No idea what that thinks it is.. :)

If these filesystems are ext2 or ext3, the look into these commands. If it's not, then *DO NOT*.. ;) Even then, these commands are potentially destructive!

e2fsck -b 32768 -n /dev/sdb1

This won't touch anything, but it'll look real hard. This tells 'fsck' to check the filesystem using an alternate super-block (filesystem settings) than the one at the start of the disk. It may be located at 64536 instead of 32768 however.

If this says something good, like it found issues and can fix them, then remove '-n' and try again.

If this doesn't work, then we move onto the nasty one.

mke2fs -j -S /dev/sdb1

This is nasty because it re-writes the superblocks on the filesystem. The '-j' is included for ext3 filesystems. Be aware that this doesn't touch the inode tables or data. Just the superblocks (filesystem settings).

If that works, then go back to the e2fsck above.

If you still don't have any joy, then you need to look into more heavy-duty data recovery tools.

I've only used these tools once, and unsuccessfully at that (see http://forums1.itrc.hp.com/service/forums/questionanswer.do?threadId=591609 ). I was able to restore 99% of the data on this filesystem in the end. Admittadly that took about 40 hours of manual work to do, but hey! :) If you really need the data, there's no stopping you! :)