あるSSDのすべてのデータを別のSSDに移動してみました。既存のSSDは500GB、新しいSSDは1000GBです。
まずバックアップを作成しました。
dd if=/dev/nvme0n1 | gzip -c /media/ubuntu/local/backup1.img.gz
その後、バックアップを復元しようとします。
gunzip -c /media/ubuntu/local/backup1.img.gz | dd of=/dev/nvme0n1
その後、エラーが発生します。
$ sudo e2fsck /dev/nvme0n1
e2fsck 1.46.5 (30-Dec-2021)
ext2fs_open2: Bad magic number in super-block
e2fsck: Superblock invalid, trying backup blocks...
e2fsck: Bad magic number in super-block while trying to open /dev/nvme0n1
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>
Found a gpt partition table in /dev/nvme0n1
どうすれば解決できるのかご存知ですか?
詳細は追加出力:
$ lsblk -f
NAME FSTYPE FSVER LABEL UUID FSAVAIL FSUSE% MOUNTPOINTS
sdc
└─sdc1 ntfs local 824A5D3E4A5D2FE1 244G 49% /media/ubuntu/local
nvme0n1
├─nvme0n1p1
├─nvme0n1p2
├─nvme0n1p3
├─nvme0n1p4
├─nvme0n1p5
├─nvme0n1p6
└─nvme0n1p7
答え1
Live Debian USBセッションでKDEパーティションマネージャを使用してext4 debian "/"パーティションを移動できなかったときにこの問題が発生しました。
私に長い話:古いライブUSBインストールを使用していて、ライブLinux USBサムドライブを再インストール/再書き込みするにはあまりにも怠惰なので、問題は古いまたは破損したUSBドライブにあるようです。 KDEパーティションマネージャが3番目(パーティションを左に移動)した2つの操作が正常に実行された後、プログラムは失敗し、エラーを報告します。再起動時に起動できないext4パーティションとマウントできない()パーティションが残りましたmount: wrong fs type, bad option, bad superblock on /dev/nvme0n1p6
。
fsck /dev/nvme0n1p6
そのパーティションまたはディスク(または)を確認すると、fsck /dev/nvme0n1
メッセージが報告されました。Bad magic number in super-block
元の投稿と同じ問題です。
動作しない:
e2fsck -b 32768 <device>
提案に従ってください
実行された操作:
- テストディスク! ! ! (下記でよく読んでください)
疑いがあるように、問題は(パーティションが移動されたかのように)変更されたパーティションテーブルにありますが、移動されたデータ(ファイル)には問題がないようです。修正および修正またはまた覆う腐食しないパーティションテーブル私が使用した元の状態でtestdisk
(apt install testdisk
、チュートリアル(https://www.cgsecurity.org/wiki/TestDisk_Step_By_Step)[deepsearch]
testdiskを介して実行し、新しいパーティションテーブル(元のもの(破損していない)に似ています)に表示したいパーティション(P(保存、無視/割り当てられていないスペースの場合はDとしてマーク))を選択する(右、左矢印)します。つまり、古いパーティションと新しいパーティションテーブルはそのステップにあります。可能返品ファイルのリスト(によるとP
)失われたパーティションに正しいパーティションを復元していることを確認してください。 「このパーティションにファイルが見つかりません」というメッセージが表示された場合は、目的のパーティションのパーティションテーブル情報(開始/終了セクタ)が間違っています。
ターゲットディスクで比較(開始、終了、およびセクタ番号を含む)を使用し、正しいfdisk -l
(問題のない)パーティションを正しく選択してプロセスから削除されるのを防ぐのに役立ちます。
使用後にパーティションテーブルをディスクに書き込むことをtestdisk
選択します。[write]
これでパーティションを再マウントできます。
答え2
partprobe /dev/nvme0n1
このようにフルディスクイメージバックアップを復元したら、カーネルがディスクパーティション化について正しい考えを持っていることを確認するために実行する必要があります。
lsblk -f
7つのパーティションが表示され、そのパーティションに認識されるファイルシステムの種類がないという事実は、nvme0n1
バックアップを復元した後にカーネルのディスクパーティション化のアイデアが時代遅れになる可能性があることを示唆しています。
元のディスク(および回復されたディスクイメージ)が分割されている場合、e2fsck
そのデバイスで実行することは決して適切ではありません/dev/nvme0n1
。適切に分割されたデバイスを対象とする必要があります。事実はe2fsck
こう言います。
Found a gpt partition table in /dev/nvme0n1
/dev/nvme0n1
つまり、ディスクが明確に分割されているため、いかなる種類のファイルシステムチェックも実行しないでください。
ただし、ソースディスクが元のmkfs
パーティションを持たない単一のファイルシステムとして意図されている場合(=「スーパーフロッピー構成」と呼ばれる)、これはe2fsck /dev/nvme0n1
適切です。ただし、ディスクのファイルシステムタイプがまたはである場合にのみext2
可能ext3
ですext4
。
ディスクまたはパーティションに他の種類のファイルシステムが含まれている場合、これはe2fsck
正しいツールではありません。正しいファイルシステムタイプ固有のツールを使用する必要があります。
答え3
私はこれが古いフォーラムであることを知っていますが、ddを使用してLinuxディストリビューションISOをUSBに書き込むことで、USBの誤ったスーパーブロックエラーを修正しました。その後、gpartedでext4としてフォーマットしてfsckを実行しましたが、エラーは表示されませんでした。