Mtpfsシステムをマウントした後、ある時点でハードドライブが破損しました。それを修正する方法を尋ねますが、パーティションとファイルシステムの種類については自信がありません。
私のOSは新しいFedoraCore 23ですが、パーティションは元々FC 20で作成されており、デフォルトの場合と同じです。
cat /proc/version
Linux version 4.2.3-300.fc23.x86_64
[email protected])
(gcc version 5.1.1 20150618 (Red Hat 5.1.1-4)
(GCC) ) #1 SMP Mon Oct 5 15:42:54 UTC 2015
Fdiskプログラムは、次のパーティションを次のように報告します。ご想像のとおり、私は/ dev/sdb3に最も興味がありますが、それが最も破損しています。/dev/sdb2が「Microsoft基本データ」を報告する理由はわかりませんが、少なくともマウントして読み取ることができますが、/ dev/sdb3パーティションはマウントできません。
Sudo fdisk /dev/sdb
Welcome to fdisk (util-linux 2.27).
Changes will remain in memory only, until you decide to write them.
Be careful before using the write command.
Command (m for help): p
Disk /dev/sdb: 931.5 GiB, 1000204886016 bytes, 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
Disklabel type: gpt
Disk identifier: 59CA4127-4BEE-40F4-A514-9DA368C81665
Device Start End Sectors Size Type
/dev/sdb1 2048 411647 409600 200M EFI System
/dev/sdb2 411648 1435647 1024000 500M Microsoft basic data
/dev/sdb3 1435648 1953523711 1952088064 930.8G Linux filesystem
Sudo mount /dev/sdb3 /mnt/sdb3
mount: /dev/sdb3 is write-protected, mounting read-only
mount: wrong fs type, bad option, bad superblock on /dev/sdb3,
missing codepage or helper program, or other error
In some cases useful info is found in syslog - try
dmesg | tail or so.
マウント、パーティション、またはdmesgやjournalctlを介したsystemdログに関連するものは何も表示されませんでした。
どうやら、スーパーブロックが見つかりませんでした:
Sudo dumpe2fs /dev/sdb3
dumpe2fs 1.42.13 (17-May-2015)
dumpe2fs: Bad magic number in super-block while trying to open /dev/sdb3
Couldn't find valid filesystem superblock.
私の質問は次のとおりです。/mnt/sdb3は実際にはどのファイルシステムですか?どうすればわかりますか(どこかに見つけて捨てることができる魔法の番号や目印はありますか)?
これを知ったら、それに応じてパーティションタイプを変更できるでしょう。 TestDiskユーティリティは、たとえば/ dev/sdb3がext4であるdosパーティションスキームなど、ファイルシステムが何であるかをknowしかできない場合に役立ちます。
更新:セットアップ時に暗号化して戻したと思います。/dev/sdb3パーティションを16進エディターで表示し、その大部分を文字列にパイプしましたが、何も認識しませんでした。繰り返しパターンのように見えるものがたくさんあります。また、私の古いgrub.cfgには次の行があります。
linuxefi /vmlinuz-3.19.8-100.fc20.x86_64 root=/dev/mapper/Fedora_ralph-root ro rd.lvm.lv=Fedora_ralphdfl/swap vconsole.font=latarcyrheb-Sun16 rd.lvm.lv=Fedora_ralphdfl/root rd.luks.uuid=luks-a0d2613e-ce2a-4a6b-96cf-b999b3a36ab8 rhgb quiet LANG=en_US.UTF-8
残念ながら、暗号化されたドライブとして認識されていません。cryptsetup-v luksDump/dev/sdb3デバイス/ dev/sdb3は有効なLUKSデバイスではありません。コマンドがコード22で失敗しました:引数が無効です
ただし、古いパスフレーズを取得することは可能です。この時点で、データ復旧会社に持って行ったほうがいいでしょうか?私はそれの多くを失う可能性がありますが、私が本当に取り戻したいいくつかの重要なファイルがあります。
前もって感謝します。
ファイルシステムの最初のセクターに損傷がない場合は、 file
コマンド から始めます。 -s
オプションを渡すと、「デバイスです」とだけ言うのではなく、デバイスのコンテンツが表示されます。
file -s /dev/sdb3
file
が使用するデータベースは、マウント時にカーネルが使用するデータベースと同じではないため、file
がカーネルが認識しているファイルシステムを認識しない場合や、その逆の場合があります。しかし、一般的な状況では、file
はカーネルがサポートするものを認識する必要があります。
file
が認識しないエキゾチックなファイルシステムまたはボリュームタイプであるためにそれが役に立たない場合は、head -c 1024k /dev/sdb3 | strings | less
を試して、それが手がかりをもたらすかどうかを確認してください。
理解できない場合は、 TestDisk などのフォレンジックツールを試してください。実行するファイルシステムのタイプを知る必要はありません。ファイルシステムを使用して、損傷したディスクを探索できます。これがポイントです。パーティションテーブルが破損していると思われる場合は、TestDiskもそれを推測しようとします。
デフォルトでは、Fedoraインストーラーは「Fedora」などと呼ばれるLVMグループを作成します。試してみてください:
# lvdisplay
または
# ls /dev/mapper/
1つは、lvmがあり、パーティションを直接マウントすることはできません
「fsck」が役立つかもしれません。例えば:
[root@master dtb]# fsck /dev/sdb1
fsck,come from util-linux 2.20.1
e2fsck 1.42.9 (4-Feb-2014)
/dev/sdb1: clean, 11/2560 files, 1445/10240 blocks
[root@master dtb]# fsck /dev/sdb5
fsck,come from util-linux 2.20.1
If you wish to check the consistency of an XFS filesystem or
repair a damaged filesystem, see xfs_check(8) and xfs_repair(8).
ハードドライバーが使用しているファイルシステムファミリーが表示されます。