Как получить доступ к файлам на диске из старой системы, установленной в новой системе?

Недавно я построил новую систему, после того, как моя предыдущая система получила довольно большую физическую травму (неустойчивый баланс и сила тяжести, не были счастливой мишенью). Удивительно, что у /home привода этой системы больше или меньше выжила травма. Однако…

Я решил использовать свежий диск для /swap ) разделов (ов) и еще один новый диск для нового /home . Теперь, когда я работаю, я решил установить старый /home диск (который я предполагал до сих пор полностью мертв и без возможности использовать) в новую систему для восстановления файлов и данных (насколько это возможно).

В этот момент я столкнулся с проблемой: я понятия не имею, как это сделать (с Windows это было относительно легко, новый диск был бы последним символом алфавита и пошел оттуда).

С «дисковой утилитой» (System -> Administration -> Disk Utitlity) я разработал, какой диск это ( /dev/sda ), но нажатие на «mount» вызывает ошибку:

1: хелпер не удалось:

mount: согласно mtab, / dev / sdb1 уже установлен на /

не удалось монтировать

… если он установлен на / я не вижу его. Я также умеренно смущен диском (device /dev/sda ), называемым /dev/sdb1 .

Любые и все идеи были бы невероятно приветствуются (я уже голосовал за: Idea # 9063: новые внутренние жесткие диски по умолчанию автоматически на Brainstorm ).


Отредактировано в ответ на запрос Роланда на скриншот дисковой утилиты:

Подробности (насколько я их знаю):

  1. 40 ГБ диск / и swap ,
  2. 1.0 ТБ Samsung /home
  3. 1.0 TB Hitachi из старой системы (и был старым /home приводом).

Выход из sudo fdisk -l вставленного ниже:

 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 

Отредактировано в ответ на ответ @Danny Staple:

Я запустил следующее:

 udo mkdir /mnt/oldhome sudo mount -t ext3 /dev/sda1 /mnt/oldhome 

Первая часть работает так, как ожидалось, и создает каталог, вторая часть запускается некоторое время и ошибки со следующим:

 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 

Должен признаться, что я начинаю считать, что отчет SMART, в котором говорится о том, что диск здоров с «несколькими» плохими секторами, может быть немного неточным.


Отредактировано , по просьбе @Danny Staple (ниже), с выходом dmesg | tail 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 


Окончательное редактирование:

Это моя печальная обязанность делиться новостями о безвременной гибели одного 1,0 ГБ Hitachi, из-за того, что я берусь от сердечных кликов в последние минуты жизни, механического повреждения, вызванного осенью. Это, и его много содержания, будет очень упущено.

К сожалению, данные не были восстановлены ни одним из предложений, поднятых в этом вопросе, что оставляет меня в несколько неудобной позиции: я не хочу иметь вопрос без ответа, поэтому я буду участвовать в голосовании сообщества и принять @ Ответ Дэнни Стэпл, поскольку он казался самым многообещающим предложением (и, опять же, был самым общинным ответом), но в будущем я буду отмечать для поздних гостей, что этот вопрос не был (действительно) разрешен, поэтому решение, предлагаемое @ Danny может или не может работать для других.

Спасибо всем за вашу помощь и предложения.