sha1sum は同じでもチェックサムの不一致を報告します。

sha1sum は同じでもチェックサムの不一致を報告します。

たぶん私はここで本当に愚かなことをしているかもしれませんが、Googleはこの問題を解決するのに大きな助けにはなりません。

バックアップ目的で使用するファイルアーカイブがあります。このアーカイブからSHA1チェックサムファイルを生成しました。

sha1sum myarchive.tar > myarchive.tar.sha1

ファイルの内容は次のとおりです。

6f5d7bdd71fe25ed8e881265fdb8a8bbcdaa41c1  myarchive.tar

また、ファイルに接続せずに端末でSHA1プロセスを実行しました。

sha1sum myarchive.tar

結果は次のとおりです。

6f5d7bdd71fe25ed8e881265fdb8a8bbcdaa41c1  myarchive.tar

明らかに、これらのチェックサムは同じです。ただし、verify コマンドを実行すると、アーカイブとその SHA1 ファイルが同じディレクトリに並んでいます。

sha1sum -c myarchive.tar.sha1

チェックサムが一致しないというエラーが発生します。

myarchive.tar: FAILED
sha1sum: WARNING: 1 computed checksum did NOT match

ここには明らかに何か問題があるようですが、それが何なのかはわかりません。誰でも私に気付くことができますか?

編集:興味深いことに、ファイルに対して2つの連続MD5を実行すると、2つの異なるチェックサムが作成されます。今私は混乱しました。

$ md5sum myarchive.tar
9a15036eed341613bbcf2c4b53a09859  myarchive.tar
$ md5sum myarchive.tar
a662d6b469627c62f2b03ee0df067436  myarchive.tar

編集2:追加のコンテキスト:

  • これは実際のハードウェア(私のUbuntu MATE 19.10デスクトップ)にあります。
  • 私が作成したアーカイブはBlu-rayバックアップディスク用でした。サイズは22.6GBです。
  • Blu-rayディスクに焼き付けたファイルのSHA1検証が最終的に成功しました。

EDIT3:出力表示要求に応答して、以下のようなdmesgいくつかのエラーがあるようです。

[ 7102.039819] perf: interrupt took too long (2502 > 2500), lowering kernel.perf_event_max_sample_rate to 79750
[ 8278.017874] sr 4:0:0:0: [sr0] tag#0 FAILED Result: hostbyte=DID_OK driverbyte=DRIVER_SENSE
[ 8278.017876] sr 4:0:0:0: [sr0] tag#0 Sense Key : Blank Check [current] 
[ 8278.017877] sr 4:0:0:0: [sr0] tag#0 Add. Sense: No additional sense information
[ 8278.017878] sr 4:0:0:0: [sr0] tag#0 CDB: Read(10) 28 00 00 00 00 00 00 00 01 00
[ 8278.017879] blk_update_request: critical target error, dev sr0, sector 0 op 0x0:(READ) flags 0x80700 phys_seg 1 prio class 0
[ 8278.019391] sr 4:0:0:0: [sr0] tag#0 FAILED Result: hostbyte=DID_OK driverbyte=DRIVER_SENSE
[ 8278.019392] sr 4:0:0:0: [sr0] tag#0 Sense Key : Blank Check [current] 
[ 8278.019392] sr 4:0:0:0: [sr0] tag#0 Add. Sense: No additional sense information
[ 8278.019393] sr 4:0:0:0: [sr0] tag#0 CDB: Read(10) 28 00 00 00 00 00 00 00 01 00
[ 8278.019394] blk_update_request: critical target error, dev sr0, sector 0 op 0x0:(READ) flags 0x0 phys_seg 1 prio class 0
[ 8278.019396] Buffer I/O error on dev sr0, logical block 0, async page read

誰かが私を修正することができますが、これは私のUSB Blu-rayドライブに関連していると思います。

ベストアンサー1

あなたの場合には、慎重な調査が必要な2つのことがあります。


ブルーレイディスク

出力クリップからわかるように、dmesgBlu-rayディスクの寿命が終わりました。いいえ固定するBlu-rayドライブがBlu-rayディスクのデータを100%正しく読み取れない場合、これは現在不可能です。

Blu-rayディスクの個人的な推奨事項:何らかの理由でBlu-rayドライブを使用して何かを焼く必要がある場合は、M-Disc(ウィキペディア)ブルーレイディスク。非常に敏感な場合小さいデータの保存はほぼ完璧です。


コンピュータのストレージスペース

コンピュータリポジトリから異なる連続チェックサムを読むことは、リポジトリから読むことであれば私をより迷惑にするでしょう。理論的には記憶力が悪いかもしれませんが、その可能性はほとんどありません。私の提案は観察することですdmesgマニュアルページ) 長い間、これらのコマンドの例は次のとおりです。

\dmesg --human --color=auto --ctime --level=err,warn --follow

これは、ストレージ(クラシックSATA HDDであるか最新のM.2 NVMe SSDであるかにかかわらず)にエラーがないかどうかを判断するのに役立ちます。あなたが本当にそこにそれを見つけた場合はいストレージに問題があります。バックアップを準備するのが最善です。


この答えが似たような場所にいる誰かに役立つことを願っています。

おすすめ記事