Tag Info

Hot answers tagged

6

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 ...


4

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 ...


4

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 ...


3

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 ...


3

I'm not sure how you can examine any particular superblock, but you can use this command to examine the general contents that all the superblocks share like so, using dumpe2fs. $ sudo dumpe2fs /dev/mapper/fedora_greeneggs-home | less Example $ sudo dumpe2fs /dev/mapper/fedora_greeneggs-home | less Filesystem volume name: <none> Last mounted on: ...


2

If it's 0.90 superblock format, you should be able to just use a member directly (in read only mode if you please). That gives you access to your data and then you can create a new fresh RAID-1 with just the other disk, copy your data over, then add the original disk to the RAID. If it's something else though (like 1.2 metadata) you'd first have to find the ...


2

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 ...


2

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 ...


2

Unfortunately, I was unable to recover the file system and had to resort to lower-level data recovery techniques (nicely summarised in Ubuntu's Data Recovery wiki entry), of which Sleuth Kit proved most useful. Marking as answered for cleanliness' sake.


1

The resize_inode feature creates a hidden inode ( number 7, you can view it in debugfs with stat <7> ) to reserve those blocks so that the GDT can be grown. By default it reserves enough space to grow the filesystem to 1024 times its original size. You can disable the feature or adjust the size using options to mke2fs at format time. What does ...


1

If the filesystem is really on that device, running mkfs.ext4 with the same arguments plus a -n will give you a list of superblocks that you can use as alternates. Eg: # mkfs.ext4 -n /dev/vg1/lvol2 ... Superblock backups stored on blocks: 32768, 98304, 163840, 229376, 294912, 819200, 884736, 1605632, 2654208 Then you can run e2fsck -b 32768 ...


1

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, ...


1

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 ...


1

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 ...



Only top voted, non community-wiki answers of a minimum length are eligible