Tag Info

Simply run mdadm --build -l1 -n2 /dev/md0 /dev/dm-10 /dev/dm11 to get your data back. Verify that the devices are correct (or use the aliases from /dev/mapper) before doing this! Also, if your kernel has already used (or is using) one of these devices, data will be inconsistent. You should set up the second device as a degenerate 1.2 array, copy the data ...

You don't seem to have a separate home partition. /dev/sda3 is an extended partition (hence the "Étendue" in fdisk -l), you will not be able to mount it and it will not contain your /home. Unless you have a 2nd hard disk, it appears you deleted your /home partition while installing Windows. The only partitions in sda are the Windows one (sda1), what I ...

If it's RAID 1 with 0.90 superblock, you should be able to mount directly without using the RAID layer at all. Data starts without offset at the beginning of the disk, so there should be no problem. Use the read-only mount option or a read-only loop device for the experiment just in case. If that works, the simplest method would be to use the other disk to ...

Have a look at this question. I assume that is familiar to your problem. Recreating and even syncing a RAID-1 should not destroy data. Obviously the MD device starts at another offset now. Thus where mount looks for a superblock there is data. This can have happened in at least two ways: You (or rather: the default setting) have created the new array with ...

Reverting the devices to their original size should just restore the RAID device. You can confirm that by doing: losetup --sizelimit=$((1230*(2**30))) -r /dev/loop1 /dev/dm-10 mdadm -E /dev/loop1 mdadm should now find the superblock if the size is correct. Then you can resize your disks back to that size (-r above is for read-only, so it won't do any ...

Recovering a damaged reiserfs partition can sometimes destroy the data you're trying to recover (I know, I've done it). So, first off, take a drive level image of the whole disk to something else. dd if=/dev/source of=/home/diskimage.img After you've got the disk image taken, then, and only then, try an fsck or other recovery. There are several links ...

This may be outdated already, but a few suggestions: If you are absolutely sure that the original blocksize is 4096, as claimed by testdisk, you can rewrite the superblocks on the disk using mke2fs -S. From man: -S Write superblock and group descriptors only. This is useful if all of the superblock and backup superblocks are corrupted, ...

I'm afraid there isn't a recognizable filesystem on this partition any more. It's time to restore from a backup. Just in case there's a hardware problem such as bad RAM or a bad cable that's causing wrong data to be read, you can try reading from another machine. But that's very unlikely to be the case if you can neither boot from the partition nor read it ...

You don't mention that you were making configuration changes before you rebooted and got the error. If you were making changes then that might give a clue as to where to look. However assuming that this just happened without any configuration being changed. First off you may have a real disk problem. Look at the output from the dmesg command and see if ...