On my personal home computer running Kubuntu Linux 13.04 I’m having trouble mounting a partition that is very dear to me. My backup policy is to perform a backup about monthly, so I do have a backup from August :). Is there any way to recover the personal files that are on this drive?
The drive is a 1.5 year old 1000 GiB Western Digital Green drive, with home mounted on /dev/sdc2, the filesystem root on /dev/sdc6, and media files on /dev/sdc3. Therefore of course sdc2 would be the one to go! So far as I know there were no power outages or other such events during the life of the drive. I managed to get this information by running a Kubuntu LiveCD:
<a href="https://getridbug.com/cdn-cgi/l/email-protection" class="__cf_email__" data-cfemail="84eff1e6f1eaf0f1c4eff1e6f1eaf0f1">[email protected]</a>:~$ sudo fdisk -l
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: 0x00008044
Device Boot Start End Blocks Id System
/dev/sdc1 * 4094 88066047 44030977 5 Extended
/dev/sdc2 88066048 1419266047 665600000 83 Linux
/dev/sdc3 1419266048 1953523711 267128832 83 Linux
/dev/sdc5 4096 6146047 3070976 82 Linux swap / Solaris
/dev/sdc6 6148096 47106047 20478976 83 Linux
/dev/sdc7 47108096 88066047 20478976 83 Linux
<a href="https://getridbug.com/cdn-cgi/l/email-protection" class="__cf_email__" data-cfemail="18736d7a6d766c6d58736d7a6d766c6d">[email protected]</a>:~$ sudo mount -t ext4 /dev/sdc2 c1
mount: wrong fs type, bad option, bad superblock on /dev/sdc2,
missing codepage or helper program, or other error
In some cases useful info is found in syslog - try
dmesg | tail or so
<a href="https://getridbug.com/cdn-cgi/l/email-protection" class="__cf_email__" data-cfemail="a3c8d6c1d6cdd7d6e3c8d6c1d6cdd7d6">[email protected]</a>:~$ sudo debugfs -c /dev/sdc2
debugfs 1.42.5 (29-Jul-2012)
/dev/sdc2: Attempt to read block from filesystem resulted in short read while opening filesystem
debugfs: quit
<a href="https://getridbug.com/cdn-cgi/l/email-protection" class="__cf_email__" data-cfemail="48233d2a3d263c3d08233d2a3d263c3d">[email protected]</a>:~$ sudo fsck /dev/sdc2
fsck from util-linux 2.20.1
e2fsck 1.42.5 (29-Jul-2012)
fsck.ext4: Attempt to read block from filesystem resulted in short read while trying to open /dev/sdc2
Could this be a zero-length partition?
<a href="https://getridbug.com/cdn-cgi/l/email-protection" class="__cf_email__" data-cfemail="2b405e495e455f5e6b405e495e455f5e">[email protected]</a>:~$ sudo fsck.ext4 -v /dev/sdc2
e2fsck 1.42.5 (29-Jul-2012)
fsck.ext4: Attempt to read block from filesystem resulted in short read while trying to open /dev/sdc2
Could this be a zero-length partition?
<a href="https://getridbug.com/cdn-cgi/l/email-protection" class="__cf_email__" data-cfemail="0a617f687f647e7f4a617f687f647e7f">[email protected]</a>:~$ dmesg | tail
[ 2684.532855] Descriptor sense data with sense descriptors (in hex):
[ 2684.532858] 72 03 11 04 00 00 00 0c 00 0a 80 00 00 00 00 00
[ 2684.532876] 05 3f c8 b0
[ 2684.532885] sd 5:0:0:0: [sdc]
[ 2684.532893] Add. Sense: Unrecovered read error - auto reallocate failed
[ 2684.532898] sd 5:0:0:0: [sdc] CDB:
[ 2684.532902] Read(10): 28 00 05 3f c8 b0 00 00 08 00
[ 2684.532917] end_request: I/O error, dev sdc, sector 88066224
[ 2684.532927] Buffer I/O error on device sdc2, logical block 22
[ 2684.532973] ata6: EH complete
Help me Unix & Linux, you’re our only hope.
Answers:
Thank you for visiting the Q&A section on Magenaut. Please note that all the answers may not help you solve the issue immediately. So please treat them as advisements. If you found the post helpful (or not), leave a comment & I’ll get back to you as soon as possible.
Method 1
(I know this is an old question, I came across this problem myself and got my FS back to life without ddrescue, so I’ll share the expericence for anyone else encountering this)
Ext filesystems store backups of the superblock — for an occasion just like this one.
First, determine the locations of the backups (make sure you have the -n option! otherwise this will wipe the file system with a new one):
mke2fs -n /dev/sdxx
This is a test run (i.e. no write) of FS creation routine. It will let you know the offsets of where it would put superblock backups if it were creating a filesystem. If you know your FS block size to be something other than 4096, you must also specify the parameter -b {blocksize} to get the right numbers.
For 4096-sized blocks, first backup superblock will be at 32768. If the following operations fail with the same error message about bad superblock/short read, try the next superblock backup from the list mke2fs gave you.
Next, you can either mount the filesystem using the backup superblock like this
mount -o sb=32768 /dev/sdxx /mnt/sdxx
then explore the FS from your file manager, copy undamaged files etc.
Or, to actually fix the FS, you can run fsck with backup superblock like this
e2fsck -fy -b 32768 /dev/sdxx
Here -f makes it scan the disk even if it’s not dirty and -y answers yes to all enquiries about fixing stuff. The -b option, aside from specifying the backup superblock, will make it update the original superblock with info from backup.
After this, you should have your filesystem back.
If e2fsck fails to write the main superblock
If the superblock got corrupted because it’s on a bad sector e2fsck will finish the run, attempt to update the superblock, and give you the following error message:
Error writing block 1 (Attempt to write block from filesystem resulted in short write)
Obviously, the main superblock isn’t updated and the whole e2fsck run is in vain.
You need to hint the disk to remap that sector — by writing zeroes to it. Thanks to @Keith for pointing this out: the next command can make a lot of mess if mistyped, so triple-check it before running. Here’s the magic:
dd if=/dev/zero of=/dev/sdxx bs=4096 count=1 seek=0
This will write 1 4096-sized block of zeroes to sdxx at offset 0. Don’t forget to account for different block size if that’s the case for you.
After that you’ll be able to write to superblock (which will be on a different physical sector transparently to you). Now, you run the e2fsck command above again and it should succeed writing the superblock allowing you to mount the FS normally.
Goes without saying Now you should backup the critical data to another physical drive and, if you still plan on using the filesystem, run
e2fsck -fccy /dev/sdxx
PS Kudos to @Nemo on this find: in case all of the backups of the superblock of your FS are corrupted, mke2fs/mkfs has the -S option that will re-create the superblock and group descriptors as if creating a new filesystem, without touching anything else. But you absolutely have to be sure your blocksize is right and the man page says you should run e2fsck after it and there are no guarantees about data being left for rescuing. Read the man page and throw a plus on this answer.
Method 2
There might still be hope, but your drive seems to have hardware problems (my interpretation of the read error in dmesg output).
You should try to make a copy of what is recoverable from that partition onto another drive (to minimize disc access). Use ddrescue for that, it might take a while but gets most if not all of the recoverable data of the partition.
If possible start from another disc, from a Live CD, or connect the drive to a different computer that has its own Linux to boot from. The reason I would do so is that the read errors while doing ddrescue probably has an impact on the disc access speed on the other partitions.
Once you have that copy, lets call that the original copy, as file on another disc, make a copy of that copy. Then try to do a filesystem check on that copy. If that recovery scrambles the copy, you can start from the original copy and try once more, something else.
All methods was sourced from stackoverflow.com or stackexchange.com, is licensed under cc by-sa 2.5, cc by-sa 3.0 and cc by-sa 4.0