Take the 2-minute tour ×
Unix & Linux Stack Exchange is a question and answer site for users of Linux, FreeBSD and other Un*x-like operating systems.. It's 100% free, no registration required.

Some background

  • The disk itself was "worked on" by a friend and is said to be still intact, undamaged and still mountable/recoverable
  • The disk was part of a software raid 1 on Ubuntu 12.04
  • The other disk in the original raid 1 was formatted and used for another purpose, leaving the current disk (the one in question) still technically part of a raid that no longer exists

What I have tried already

  • Basic mounting

    • I added an entry to fstab, marked the disk as ext3/ext4 and tried to mount.
    • Upon mounting the following error appears

      wrong fs type, bad option, bad superblock on

    • And in dmesg

      EXT4-fs (sdc1): VFS: Can't find ext4 filesystem

  • I have tried to find the file system type of the disk and have come up with

    $sudo file -s /dev/sdc
    /dev/sdc: x86 boot sector; partition 1: ID=0x83, starthead 254, startsector 63, 1953520002 sectors, code offset 0xb8

Where I need some help / My Questions

  • Is there a way to convert the disk to ext4 without damaging the data?
  • Is there a simple way to mount the Linux 83 file type disk and recover the data?
  • I have another disk currently free in case it is a possibility to somehow rebuild the raid
  • My main goal is to recover the data from the disk. I am open to all options.

Update

Some commands' output

  • fdisk -l /dev/sdc

    $fdisk -l /dev/sdc

    Disk /dev/sdc: 1000.2 GB, 1000204886016 bytes
    255 heads, 63 sectors/track, 121601 cylinders, total 1953525168 sectors
    Units = sectors of 1 * 512 = 512 bytes
    Sector size (logical/physical): 512 bytes / 512 bytes
    I/O size (minimum/optimal): 512 bytes / 512 bytes
    Disk identifier: 0x0005ed9c

    Device Boot Start End Blocks Id System
    /dev/sdc1 63 1953520064 976760001 83 Linux

  • file -s /dev/sdc1

    $file -s /dev/sdc1
    /dev/sdc1: data

  • hexdump -C -n 32256 /dev/sdc (Not sure if this could help or not)

    $hexdump -C -n 32256 /dev/sdc`
    00000000  fa b8 00 10 8e d0 bc 00  b0 b8 00 00 8e d8 8e c0  |................|
    00000010  fb be 00 7c bf 00 06 b9  00 02 f3 a4 ea 21 06 00  |...|.........!..|
    00000020  00 be be 07 38 04 75 0b  83 c6 10 81 fe fe 07 75  |....8.u........u|
    00000030  f3 eb 16 b4 02 b0 01 bb  00 7c b2 80 8a 74 01 8b  |.........|...t..|
    00000040  4c 02 cd 13 ea 00 7c 00  00 eb fe 00 00 00 00 00  |L.....|.........|
    00000050  00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00  |................|
    *
    000001b0  00 00 00 00 00 00 00 00  9c ed 05 00 00 00 00 fe  |................|
    000001c0  ff ff 83 fe ff ff 3f 00  00 00 82 59 70 74 00 00  |......?....Ypt..|
    000001d0  00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00  |................|
    *
    000001f0  00 00 00 00 00 00 00 00  00 00 00 00 00 00 55 aa  |..............U.|
    00000200  00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00  |................|
    *
    00007e00
    
share|improve this question
    
The problem is that the partition thinks it has some raid volume on it and not an ext4fs. And the kernel is right. However as it was a raid 1 it happens to be an ext4fs. a mount -f ext4 /dev/sdc1 /mountpoint should do the trick. To force mount to assume ext4 instead of looking for a file system is what -f does –  Bananguin Feb 15 '13 at 18:21
1  
The force mount doesn't give any errors, but the mount point is blank. Either the data is gone, or the mount didn't work as expected. Doing a df shows me that the newly mounted disk is 2% in use which is significantly lower than expected. –  Adam Feb 15 '13 at 21:22
    
@user1129682, if mount says it isn't ext4, then it isn't... trying to force it isn't going to help. –  psusi Feb 16 '13 at 0:45
    
@psusi: worked for me. Gilles answer explainns why it works under some circumstances –  Bananguin Feb 16 '13 at 18:44
add comment

3 Answers

Linux mdraid has several metadata formats. Formats 0.9 and 1.0 put the metadata at the end of the containing device, and the payload (the filesystem) starts at the beginning of the device and can be accessed directly without going through the raid layer. Formats 1.1 and 1.2 put the metadata at the middle and beginning of the containing device respectively, so the payload is at an offset.

The Ubuntu installer creates volumes with the 1.2 metadata format, so your data starts after the metadata instead of at the beginning of the device.

The simplest way to access that data is to assemble the raid device. In a RAID-1 volume, a single device is sufficient.

madadm -A /dev/sdc1

(Stop here unless you like pain.)

You can also access the data at an offset. The only point I can see to doing this is if you have to work in a very old kernel that doesn't support 1.x mdraid formats. First, determine the offset mdadm -E /dev/sdc1: look for the line Data Offset : SSS sectors. An mdadm sector is 512 bytes.

sectors=$(mdadm -E /dev/sdc1 | awk -F: '$1 ~ /Data offset/ {print $2}')
bytes=$(($sectors * 512))
losetup -f -o $bytes /dev/sdc1

In desperation, with 1.x formats, the data offset is stored in bytes 128–135 of the metadata, little-endian¹. 1.2 metadata is 4096 bytes after the beginning of the device.

You can also change the partition table to make it start further. Be very careful with your arithmetic. Only do that if you want to keep using the disk on a long-term basis in an old system that can't access the raid device.

¹ Or with platform endianness? I'm not sure.

share|improve this answer
    
the data can start at different offsets (see mdadm -E /dev/sdc1 for where exactly) but certainly not at 4k for 1.2 metadata, since 4k is precisely where the metadata is stored. See also unix.stackexchange.com/q/57477/22565 –  Stephane Chazelas Feb 15 '13 at 23:41
    
@StephaneChazelas Oops, yes, brain fart. Thanks. –  Gilles Feb 15 '13 at 23:50
1  
mdadm -A /dev/sdc1 outputs mdadm: device /dev/sdc1 exists but is not an md array. I've gone a bit further to use mdadm and see if there is any additional info... mdadm --misc --examine /dev/sdc1 outputs mdadm: No md superblock detected on /dev/sdc1.. Is there a way that I can re-write the superblocks on this disk to mark it as an available disk for RAID assembly? –  Adam Feb 16 '13 at 17:12
    
@Gilles A mdadm -E /dev/sdc returns the following for me: /dev/sdc: MBR Magic : aa55 Partition[0] : 1953520002 sectors at 63 (type 83) but no information for /dev/sdc1 though –  Adam Feb 16 '13 at 19:05
1  
@Adam If mdadm can't find its metadata there's nothing you can do there: you can't force it to do something since it doesn't know what to do. You need to look for a filesystem, and if psusi's advice doesn't lead anywhere, the outlook is bleak. Maybe a hexdump of the first few kilobytes of the disk could inspire someone (beware that it could expose some confidential data). –  Gilles Feb 17 '13 at 11:57
show 5 more comments

To my surprise, I was/am able to recover the data by simply using foremost.

The help received here was invaluable. After trying a variety of suggested combinations, as well as my own mix-ins, the ideal method (to mount and use the disk as normal) didn't seem like an option any more. Resorting to data recovery is my solution in this case.

share|improve this answer
add comment

It seems that you have already zapped the mdadm superblock. If it used to be there and was format 1.1 or 1.2, then most likely the filesystem is at offset 2048 sectors. You can run e2fsck /dev/sdc1?offset=2048 to force it to look for the filesystem starting at that offset. If it finds it then you can modify your partition table to point to where the filesystem actually starts. You can use parted /dev/sdc and the unit s command to use units of sectors. print the table, note the start and end sector, then rm the partition, then recreate it with mkpart and use the same end sector, but add the offset to the start sector.

If 2048 does not work, you might also try 1985.

share|improve this answer
    
Running e2fsck /dev/sdc1?offset=2048 (I also ran offset=1985) outputs Bad magic number..Superblock invalid... as well as suggesting that the superblock is corrupt and trying to run e2fsck with an alternative superblock. Seems like I should provide it an alternative superblock to move forward. –  Adam Feb 16 '13 at 20:16
    
@Adam, no, you just need to get the correct offset. testdisk should be able to do a detailed scan and fix the partition table for you. –  psusi Feb 16 '13 at 20:44
    
testdisk is completely new territory for me. A basic run (Analyse) show No ext2, JFS, Reiser.. marker. Bad relative sector. No partition is bootable. It also provides the following: 1 P Linux 0 1 1 121600 254 63 1953520002 How can I make sense of that in order to help the situation? –  Adam Feb 16 '13 at 21:30
    
@Adam, I've never used it myself, I just know it is supposed to be able to scan for and find the superblock. You did run it on the whole disk, not the partition right? –  psusi Feb 16 '13 at 21:46
    
After running an analysis on the full disk, it turned up no partitions. Currently running a deep scan now. If this doesn't turn up anything, I'm not sure where to go from here. –  Adam Feb 16 '13 at 22:12
show 5 more comments

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.