I've recently built a new system, after a rather large physical injury was sustained by my previous system (a precarious balance, and gravity, were not a happy mix). Surprisingly the
/home drive of that system appears to have more-or-less survived the trauma. However...
I decided to use a fresh drive for
swap) partition(s), and another fresh drive for the new
/home. Now that's working, I decided to install the old
/home drive (that I had assumed until now would be entirely dead and without capacity for use) into the new system to recover the files and data (so far as is possible).
At this point I've run into a snag: I have no idea how to go about this (with Windows it was relatively easy, the new drive would be the latest character of the alphabet, and go from there).
With 'disk utility' (System -> Administration -> Disk Utitlity) I've worked out which drive it is (
/dev/sda) but clicking on 'mount' produces an error:
1: helper failed with:
mount: according to mtab, /dev/sdb1 is already mounted on /
...if it is mounted on
/ I can't see it. I'm also moderately confused by the disk (device
/dev/sda) being referred to as
Any and all insights would be incredibly welcome (I've already voted for: Idea #9063: New internal hard drives default automount at Brainstorm).
Edited in response to Roland's request for a screenshot of disk utility:
Details (so far as I know them):
- 40GB disk is
- 1.0 TB Samsung is
- 1.0 TB Hitachi is from the old system (and was the old
sudo fdisk -l pasted below:
Disk /dev/sda: 1000.2 GB, 1000204886016 bytes 255 heads, 63 sectors/track, 121601 cylinders Units = cylinders of 16065 * 512 = 8225280 bytes Sector size (logical/physical): 512 bytes / 512 bytes I/O size (minimum/optimal): 512 bytes / 512 bytes Disk identifier: 0x000bef00 Device Boot Start End Blocks Id System /dev/sda1 1 121601 976760001 83 Linux Disk /dev/sdb: 40.0 GB, 40018599936 bytes 255 heads, 63 sectors/track, 4865 cylinders Units = cylinders of 16065 * 512 = 8225280 bytes Sector size (logical/physical): 512 bytes / 512 bytes I/O size (minimum/optimal): 512 bytes / 512 bytes Disk identifier: 0x00037652 Device Boot Start End Blocks Id System /dev/sdb1 * 1 4742 38084608 83 Linux /dev/sdb2 4742 4866 993281 5 Extended /dev/sdb5 4742 4866 993280 82 Linux swap / Solaris Disk /dev/sdc: 1000.2 GB, 1000204886016 bytes 255 heads, 63 sectors/track, 121601 cylinders Units = cylinders of 16065 * 512 = 8225280 bytes Sector size (logical/physical): 512 bytes / 512 bytes I/O size (minimum/optimal): 512 bytes / 512 bytes Disk identifier: 0x000e8d46 Device Boot Start End Blocks Id System /dev/sdc1 1 121602 976760832 83 Linux
Edited in response to @Danny Staple's answer:
I ran the following:
udo mkdir /mnt/oldhome sudo mount -t ext3 /dev/sda1 /mnt/oldhome
The first part works as expected, and creates the directory, the second part runs for some time and errors out with the following:
mount: wrong fs type, bad option, bad superblock on /dev/sda1, missing codepage or helper program, or other error In some cases useful info is found in syslog - try dmesg | tail or so
I must confess that I'm beginning to believe that the SMART report, that suggests the disk is healthy with a 'few' bad sectors, may be a little inaccurate.
Edited, as requested by @Danny Staple (below), with the output from
dmesg | tail:
david@morpheus:~$ dmesg | tail [ 192.008425] 72 03 11 04 00 00 00 0c 00 0a 80 00 00 00 00 00 [ 192.008444] 3a 34 18 97 [ 192.008452] sd 0:0:0:0: [sda] Add. Sense: Unrecovered read error - auto reallocate failed [ 192.008464] sd 0:0:0:0: [sda] CDB: Read(10): 28 00 3a 34 18 97 00 01 00 00 [ 192.008482] end_request: I/O error, dev sda, sector 976492695 [ 192.008511] JBD: Failed to read block at offset 264 [ 192.008529] JBD: recovery failed [ 192.008536] EXT3-fs (sda1): [ 192.008541] ata1: EH complete [ 192.008547] error loading journal
It's my sad duty to share the news of the untimely death of one 1.0 TB Hitachi hard drive, due, I'm assuming from the heart-stopping clicks in its last moments of life, mechanical damage sustained in a fall. It, and its many contents, will be sorely missed.
Unfortunately the data was not recoverable by any of the suggestions raised in this question, which leaves me in a slightly awkward position: I don't want to have a non-answered question, so I'll side with the community votes and accept @Danny Staple's answer, since it seemed the most promising suggestion (and, again, was the most community-rewarded answer), but I will note for late-comers in future that this question was not (really) resolved, so the solution offered by @Danny may, or may not, work for others.
Thank you all for your help, and suggestions.