Как я могу считать HPFS/NTFS (Загрузочный) раздел на Ubuntu (15.10)?

Я хотел бы считать содержание старого жесткого диска, который отформатирован как HPFS/NTFS (Загрузочный) раздел; я не уверен, имеет ли загрузочная часть значение. Я попытался смонтировать диск, но не может. Как я могу считать этот диск?

При использовании sudo fdisk -l, диск обнаруживается как:

:~$ sudo fdisk -l
Device     Boot Start       End   Sectors   Size Id Type
/dev/sdf1  *       63 488392064 488392002 232.9G  7 HPFS/NTFS/exFAT

Использование попытки mount:

:~$ sudo mount /dev/sdf1 /mnt/ntfs1
mount: wrong fs type, bad option, bad superblock on /dev/sdf1,
       missing codepage or helper program, or other error

       In some cases useful info is found in syslog - try
       dmesg | tail or so.

Использование попытки ntfs-3g;

:~$ sudo ntfs-3g /dev/sdf1 /mnt/ntfs1
NTFS signature is missing.
Failed to mount '/dev/sdf1': Invalid argument
The device '/dev/sdf1' doesn't seem to have a valid NTFS.
Maybe the wrong device is used? Or the whole disk instead of a
partition (e.g. /dev/sda, not /dev/sda1)? Or the other way around?

Править:

Использование попытки mount -t exfat:

:~$ sudo mount -t exfat /dev/sdf1 /mnt/ntfs1
FUSE exfat 1.1.0
ERROR: exFAT file system is not found.

fsck отчет:

:~$ sudo fsck -f /dev/sdf1
fsck from util-linux 2.26.2
e2fsck 1.42.12 (29-Aug-2014)
ext2fs_open2: Bad magic number in super-block
fsck.ext2: Superblock invalid, trying backup blocks...
fsck.ext2: Bad magic number in super-block while trying to open /dev/sdf1

The superblock could not be read or does not describe a valid ext2/ext3/ext4
filesystem.  If the device is valid and it really contains an ext2/ext3/ext4
filesystem (and not swap or ufs or something else), then the superblock
is corrupt, and you might try running e2fsck with an alternate superblock:
    e2fsck -b 8193 <device>
 or
    e2fsck -b 32768 <device>
1
задан 16 February 2016 в 06:04

2 ответа

В моем случае этот вопрос был решен с помощью dislocker, поскольку у меня были окна, 10 bitlocker заблокировали жесткий диск.

1
ответ дан 7 December 2019 в 13:48

Для начала НИКОГДА не не работайте fsck на разделе, когда Вы не знаете, что выполнение так является правильным планом действий. Проблема - это fsck инструмент восстановления, и как таковой, он, вероятно, запишет данные в диск. В Вашем случае Вы применили его перед ровным знанием, какая файловая система использовалась на диске. Это чрезвычайно опасно, так как инструмент восстановления, возможно, стал запутанным и усугубил положение, а не лучше. Такой результат маловероятен, но возможен. Вы, вероятно, не причинили вреда, но существует небольшой шанс, что Вы нанесли больше ущерба диску при помощи fsck на нем.

Для изучения, какая файловая система находится на диске использовать blkid, как в:

$ sudo blkid /dev/sdb3
/dev/sdb3: UUID="493344495F520D15" TYPE="ntfs"

Конечно, Ваш вывод, вероятно, будет отличаться, но этот пример действительно показывает том NTFS. Если Вы не получаете вывода вообще, который означает это blkid не мог определить файловую систему, которая в свою очередь означает, что она очень плохо повреждена. Если там производится, но TYPE= шоу что-то другое, чем ntfs, затем это означает, что это не том NTFS. Возможно, вывод будет очевиден, и можно продолжить двигаться оттуда, или возможно необходимо будет отправить назад с деталями для большего совета.

С известной файловой системой можно использовать определенные для файловой системы инструменты монтирования и возможно восстановить инструменты. Вы уже попытались монтироваться с вероятными инструментами (NTFS и exFAT). Код типа для раздела (0x07) был однажды наиболее часто используемый для HPFS, но это будет вероятно, только если диск использовался с ОС/2, и Вы говорите, что это использовалось с Windows 7.

Перед использованием потенциально разрушительных инструментов восстановления мудро сделать резервное копирование низкого уровня, как в:

sudo dd if=/dev/sdf1 of=/path/to/lots/of/space/sdf1.img

Эта команда создает резервную копию /dev/sdf1 в файл sdf1.img в /path/to/lots/of/space/. Убедитесь, что существует достаточно свободного пространства для содержания всего раздела - приблизительно 233 гибибайта в случае. Создание этого резервного копирования даст Вам способ восстановиться, если инструмент восстановления усугубит положение, как это действительно иногда происходит.

Моя догадка - то, что диск использует NTFS, но что он поврежден и/или не был правильно закрыт. Если так, необходимо сначала восстановить его с инструментами Windows. Linux ntfsfix утилита плохо названа; это делает только большинство минимальных проверок и затем отмечает диск как бывший необходимо уделять внимание в Windows. Нет никакой поддержки Linux NTFS в fsck, таким образом, Вы не должны пытаться использовать fsck на томе NTFS.

Также возможно, что существует что-то более экзотическое продолжение. Например, диск, возможно, использовался в RAID-массиве, в этом случае Вы не смогли восстанавливать что-либо без другого диска (дисков) от того же массива. (Специфические особенности зависели бы от типа RAID используемые и другие детали.)

В худшем варианте Вы можете использовать PhotoRec для восстановления отдельных файлов.

Еще одна точка: В Ваших комментариях Вы сказали работу GParted /dev/sdf1. Это бесполезно - и даже потенциально опасно. /dev/sdf1 раздел, но GParted предназначен, чтобы использоваться на целом диске - то есть, /dev/sdf.

1
ответ дан 7 December 2019 в 13:48

Другие вопросы по тегам:

Похожие вопросы: