ddを使用してsdカードをコピーしても正確にコピーされない
SDカードを64 GBのSDカードに移動できるように、SDカードのコピーを作成しようとしています。 Raspberry PiのSDカードでこれを行いましたが、問題ありません。
SDカードは2つのパーティションで構成されます：BOOT（fat32）およびlinux（ext4）
私はSDカード全体の画像を作成しようとしました：
Sudo dd of=Images/orangepi.img if=/dev/sdd bs=1M status=progress
そしてSDカードに戻す：
Sudo dd if=Images/orangepi.img of=/dev/sdd bs=1M status=progress
2つのパーティションで構成されているため、イメージをマウントできませんでした。だから、私はBOOTとlinuxを別々にイメージしました：
Sudo dd of=linux.img if=/dev/sdd2 bs=1M status=progress
Sudo dd of=BOOT.img if=/dev/sdd1 bs=1M status=progress
追加したスクリーンショットでわかるように、SDカードから作成された画像（右側）はSDカード（左側）と一致しません。
私の質問は：なぜこれが起こるのか、どうすればSDカードの適切な画像を作成するのかということです。
SDカードのホームフォルダーには、mp3ファイルのあるフォルダーを含む「Music」というフォルダーがあります。
私の画像には、「Music」という名前のx-font.ttfがあります。画像化されると、フォルダはランダムなファイルに変化するようです。
SD-Cardは私のorangepi pcで動作するubuntuディスクであり、現在動作しています。
**Sudo apt install dcfldd
lsblk**
NAME MAJ:MIN RM SIZE RO TYPE MOUNTPOINT
sda 8:0 0 465.8G 0 disk
└─sda2 8:2 0 465.8G 0 part /media/Shared
sdb 8:16 0 238.5G 0 disk
├─sdb1 8:17 0 500M 0 part
├─sdb2 8:18 0 116.8G 0 part
├─sdb3 8:19 0 117.3G 0 part /
├─sdb4 8:20 0 1K 0 part
└─sdb5 8:21 0 3.9G 0 part [SWAP]
sdc 8:32 1 7.5G 0 disk
├─sdc1 8:33 1 64M 0 part /media/fhfs/BOOT
└─sdc2 8:34 1 7.4G 0 part /media/fhfs/linux
sdg 8:96 0 465.8G 0 disk
└─sdg1 8:97 0 465.8G 0 part /media/fhfs/0c91eeb6-7199-47b6-a603-04432a091fdc
sr0 11:0 1 1024M 0 rom
**ls -lha /dev | grep sd**
brw-rw---- 1 root disk 8, 0 Oct 18 14:54 sda
brw-rw---- 1 root disk 8, 2 Oct 18 14:54 sda2
brw-rw---- 1 root disk 8, 16 Oct 18 14:54 sdb
brw-rw---- 1 root disk 8, 17 Oct 18 14:54 sdb1
brw-rw---- 1 root disk 8, 18 Oct 18 14:54 sdb2
brw-rw---- 1 root disk 8, 19 Oct 18 14:54 sdb3
brw-rw---- 1 root disk 8, 20 Oct 18 14:54 sdb4
brw-rw---- 1 root disk 8, 21 Oct 18 14:54 sdb5
brw-rw---- 1 root disk 8, 32 Oct 20 18:11 sdc
brw-rw---- 1 root disk 8, 33 Oct 20 18:11 sdc1
brw-rw---- 1 root disk 8, 34 Oct 20 18:11 sdc2
brw-rw---- 1 root disk 8, 48 Oct 18 14:54 sdd
brw-rw---- 1 root disk 8, 64 Oct 18 14:54 sde
brw-rw---- 1 root disk 8, 80 Oct 18 14:54 sdf
brw-rw---- 1 root disk 8, 96 Oct 18 14:54 sdg
brw-rw---- 1 root disk 8, 97 Oct 18 14:54 sdg1
**Sudo dcfldd if=/dev/sdc2 of=linuxdcfl.img hash=md5,sha1 hashlog=hashlog.txt**
242944 blocks (7592Mb) written.
243056+1 records in
243056+1 records out
**Sudo dcfldd if=/dev/sdc2 vf=linuxdcfl.img verifylog=verify.log**
0 - 0: Mismatch
Total: Mismatch
Dcflddを試してみましたが、不一致がありましたが、エラーログはありませんでした。 verify.logは空です。 hashlogにはshaとmd5の合計が含まれています。
ddには、ビット複製用に正確なビットを作成した長い歴史があります。 diffは、これを非常に便利に証明するために使用できます。
注：実行しているUbuntuのバージョンについては言及しません。違いを生む唯一の理由は、ステータススイッチの使用法が変更されたことです。
Ubuntu 14.04 man ddからの抜粋
status=WHICH
WHICH info to suppress outputting to stderr; 'noxfer' suppresses
transfer stats, 'none' suppresses all
man ddからのUbuntu 16.04の抜粋
status=LEVEL
The LEVEL of information to print to stderr; 'none' suppresses everything but error messages, 'noxfer' suppresses
the final transfer statistics, 'progress' shows periodic transfer statistics
それ以外は、イメージファイルがソースとは異なるビットパターンを持つことになると考えられる唯一のものは、次のいずれかです。
ユーザーエラー：
A）マウントされたパーティションをイメージする試み（非常に悪い考え）
B）syncに失敗すると、カーネルバッファーにデータが残されます。
または
ハードウェア障害：
C）イメージを保存したディスク上の障害領域。これは、ドライブの差し迫った障害を意味します（バックアップがない場合は、ホップしてください！）
D）ソースメディアデバイスまたはターゲットメディアデバイスへの接続が不十分な危険な接続
スマートステータスを確認 イメージを保存したドライブの方が賢明でしょう。
dcflddも不一致になったという事実から、ケーブルまたは障害のあるストレージメディア（入力メディアまたは出力メディア）に障害があると思うようになります。
これは、SD/microSDチップの脆弱性に関するコメントです。
badblocksに関する上記のコメントを使用して、2つの新しい512GB microSDチップをテストしました。サイズを考えて、USB 3.0ポートにUSB 3.0カードリーダーを装着しました。チップは熱くなりました、本当に熱くなりました。次に、1000サンプルのmy標準テストを使用して、速度を確認するためにDisksを使用してベンチマークを行いました（標準の100ではなく）、再びUSB 3.0リーダー/3.0ポートで。 1つが合格し、もう1つは〜600サンプルに達し、書き込み速度は〜90 MB/sから20 MB/s未満に低下しました。その書き込み速度は元に戻りませんでしたので、USB 3.0ポートで利用可能な電力のために、私は「焼けた」と思います^。
badblocksは集中的なフルディスクの書き込み/読み取りプロセスであるため、USB 2.0カードリーダー、またはUSB 2.0ポートでUSB 3.0カードリーダーを使用することをお勧めします。大きい（高価な）チップを焼き切る可能性を最小限に抑えるため。それにはもっと時間がかかりますが、そうです。その後、standardDisks 100サンプルをベンチマークに使用することをお勧めします（USB 3.0リーダー/ USB 3.0ポート）。
（残念ながら）上記の手順を決定するために、より小さな128GB microSDチップをいくつか使用しました。それらのほとんどは、私のテストに失敗したためにRMAに戻りました。これらのチップはUSB 3.0サムドライブほど堅牢ではないため、注意が必要です。
^ところで、USB 3.0カードリーダー/ USB 3.0ポートを使用していて、同じサイズの別のチップよりもチップの時間が長くかかっている場合、すでに「焼けている」可能性があります。
SDカードに不良ブロックがある可能性があります。
書き込みモードパターンテストを実行するために、宛先SDカードで「Sudo badblocks -s -w/dev/sd＃」を実行します。/dev/sd＃に注意してください。 'badblocks -w'は破壊的です！/dev/sd＃を 'ls -l/dev/disk/by-id /'と照合して、正しいブロックデバイスがあることを確認することをお勧めします。
これをすべての新しいストレージデバイスと、疑わしいデバイスで実行します。 1 TB SATA HDDは、-wの4つのパターンの1つのパスを完了するのに約24時間かかります。 SDカードは非常に高速です。この方法で、不良なUSBフラッシュドライブ、SDカード、ハードドライブ、さらには不良なUSBマイクロSDカードリーダーをいくつか見つけました。
不良ブロック番号が表示される場合、まだ保証期間内であればデバイスのRMAを試すことができます。
.xsession-errorsファイルの日付とサイズは、写真の2つのファイルリスト間で完全に異なります。 'dd'が認識できないほどファイルシステム全体をスクランブルせずにそれを行う方法はありません。
マウントされたファイルシステムではddを使用しないでください。これは、ほとんどのシステムがSDカードを差し込むとすぐに自動マウントされるため、回避するのは困難です。
「df」と「dmesg」を使用して、SDカードの/ dev/sd_＃を見つけます。警告：複数のパーティションがある場合、そのSDカードには複数のカードが存在する可能性があります。
Sudo umount /dev/sd_#
sDカードのマウントを解除しますが、接続されたままで排出されません。
再度「df」を実行して、アンマウントされたことを確認します。
SDカード全体を読み書きするために「dd」を使用できます（元のポスターの「dd」の最初のペア）。
システムにSDカードを取り出すように指示します。 [Ubuntu 16.04では、SDカードを右クリックして[親ドライブの取り出し]を選択します。本当に「マウント」オプションと「アンマウント」オプションを追加する必要があります]イジェクトオプションが見つからない場合は、「sync」を実行し、SDカードを取り外す前に書き込みバッファーをフラッシュするプロンプトが戻るのを待ちます。
はい、cankpartxを使用してイメージ内にパーティションをマウントします
Sudo apt install kpartx
cd Images
Sudo kpartx -a orangepi.img
/ dev/mapperの下にデバイスを作成し、nautilusがデバイスを検出して、それぞれのパーティションをマウントできるようにします。
パーティションをアンマウントした後、/ dev/mapperの下のデバイスを削除するには、
cd Images
Sudo kpartx -d orangepi.img
パーティションがあなたのケースで異なる理由については、その結果を得るためにあなたが何をしたかについて、私は知りません。同じだったはずです。
個々のパーティションでddをすることは常に避けます。まったく同じ記憶媒体、同じサイズ、モデル番号を除き...
新しいカードに大きなパーティションを作成し、その過程でiノードを混乱させたようです。
あなたはあなたがイメージをマウントできなかったと言ったが、それは目的のSDカードで意図したとおりに機能するか？そうすべき...
私は推測します、あなたはより大きなカードに移動しようとしています。私が好む方法は、ddカード全体です。次に、ライブで起動するか、他のコンピューターに接続して、Gpartedをロードし、数MBのパーティションを縮小してから、フルサイズに戻します。新しい空き領域が再利用され、2〜3分しかかかりません。