OSのアップグレード後にファイルシステムが検出されません。デバッグ方法は何ですか?

OSのアップグレード後にファイルシステムが検出されません。デバッグ方法は何ですか?

2台のハードドライブを搭載したコンピュータがあります。 1つはオペレーティングシステムと他のいくつかのエントリを含み、もう1つは追加のテラバイトのストレージスペース用のダンプスペースとして/ mediaにマウントされています。最近、システムをUbuntu MaverickからDebian Jessieにアップグレードしました。これには、互換性のない複数のパッケージを削除して追加のインストールが含まれており、再起動時にハードドライブが死んでいる可能性があります。 。

そのドライブには全く重要なことはありませんが、再構築するのではなく検索したいと思います。さらに、問題を上書きして続行するのではなく、何が間違っているのかを知りたいです。だから私が要求するのは、ハードドライブのファイルシステムが認識されなくなった奇妙なハードドライブのエラーをデバッグする方法についてのアドバイスです。この質問がここで適切でない場合は謝罪し、より良い場所に案内します!

アップグレード前のプライマリドライブは/ dev / sdaで、セカンダリドライブは/ dev / sdbでした。これで、次のように表示されます。

$ sudo parted -l
Model: ATA WDC WD1002FAEX-0 (scsi)
Disk /dev/sda: 1000GB
Sector size (logical/physical): 512B/512B
Partition Table: msdos
Disk Flags: 

Number  Start   End     Size    Type     File system  Flags
 1      32.3kB  1000GB  1000GB  primary


Model: ATA ST31000333AS (scsi)
Disk /dev/sdb: 1000GB
Sector size (logical/physical): 512B/512B
Partition Table: msdos
Disk Flags: 

Number  Start   End     Size    Type      File system     Flags
 1      1049kB  997GB   997GB   primary   ext4            boot
 2      997GB   1000GB  3143MB  extended
 5      997GB   1000GB  3143MB  logical   linux-swap(v1)

/dev/sdb のファイルシステムが正しく表示されます (ほとんどの TB は ext4、ブート可能パーティション、3 GB スワップです)、/dev/sda のパーティションはほとんど正しい可能性があります (以前は設定していませんが)。アップグレード)パーティションテーブルダンプ)、ファイルシステムは一覧表示されません。

fsck /dev/sda1 を試みると、次のエラーが発生します。

$ sudo fsck /dev/sda1
fsck from util-linux 2.25.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/sda1

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>

可能なスーパーブロックオプションのリストには有用な結果はありませんでしたが、パーティションテーブルオフセットがあるかどうか疑問に思います。有効なスーパーブロックを検索する方法はありますか?

また、これがext3 / ext4ファイルシステムであるかどうか100%確信できません。他のファイルシステムを使用しているかもしれませんが、何がわかりません。追加のファイルシステムドライバをインストールできるようにパーティションをブラウズし、パーティションが何を使用するかを把握する方法はありますか?

どんなアドバイスでも役に立ちます。ありがとうございます!

編集:doktor5000はtestdiskをつかみ、内容を確認するように提案しました。

Disk /dev/sda - 1000 GB / 931 GiB - CHS 121601 255 63
Current partition structure:
     Partition                  Start        End    Size in sectors

No ext2, JFS, Reiser, cramfs or XFS marker
 1 P Linux                    0   1  1 121600 254 63 1953520002
 1 P Linux                    0   1  1 121600 254 63 1953520002
No partition is bootable

「クイック検索」を選択すると、次のような結果が表示されます。

Disk /dev/sda - 1000 GB / 931 GiB - CHS 121601 255 63
     Partition               Start        End    Size in sectors
>* Linux                    0  32 33 118619 237 18 1905627136
 P Linux Swap           118620  14 51 121601  57 56   47892480

fdiskが以前に言ったことを引用するのを忘れてしまったので、

$ sudo fdisk /dev/sda -l

Disk /dev/sda: 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: dos
Disk identifier: 0x000a56a5

Device     Boot Start        End    Sectors   Size Id Type
/dev/sda1          63 1953520064 1953520002 931.5G 83 Linux

したがって、私が見た違いは次のとおりです。 fdiskはパーティションが63で始まると思いますが、testdiskは32と言います(私の考えでは)。 testdiskはそこにスワップパーティションがあると言います。これは私にはわかりません(セカンダリドライブです。なぜスワップスペースを割り当てるのかわかりません)。でも素敵ですね。ファイルシステムをよく見て、ファイルをコピーできます!これは私が最後にディスクリカバリを試みたときに経験したものと比較すると素晴らしいです。しかし、それは1990年代のOS / 2でしたので驚くべきことではありません。 :)

私はtestdiskに新しいパーティションテーブルを作成させるのに十分自信があります。はい!すべてのデータがあり、読み取ることができ、ドライブが正常に動作しているようです。 doktor5000さん、ありがとうございました!それではフォローアップの質問です。パーティションテーブルがどのように破損したのかご存知ですか?

ベストアンサー1

最も確実な方法は、次のようにパーティションを深く検索することです。テストディスク
彼らの姿を見て実行方法に関する一般的なガイドラインそして/またはステップバイステップ文書

その後、testdiskで見つかったパーティションテーブルを現在何も変更せずに表示されているものと比較し、ここに公開することもできます。

少なくともext2/3/4のもう1つのオプションは、以下を使用することです。デバッグコマンドしかし、これははるかに複雑で、testdiskほど単純ではありません。

いずれの場合でも、そのディスクのコンテンツを回復するには、より多くのデータが失われる危険性を避けるために、そのディスクからイメージを作成し、そのイメージでのみ作業することをお勧めします。バラより故障したドライブのデータ保存これを行う方法のいくつかの提案。

おすすめ記事