копирование SD-карты с использованием dd не копирует точно

Я пытаюсь сделать копию своей SD-карты, чтобы переместить ее на свою 64-граммовую SD-карту. Я сделал это с SD-картой малины, никаких проблем нет.

SD-карта состоит из двух разделов: 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-карты.

слева - раздел Linux на SD-карте, справа - установленное изображение

В моей домашней папке SD-Card есть папка под названием «Музыка», содержащая папки с mp3-файлами.

У моего изображения есть x-font.ttf с именем «Музыка». Папки, кажется, превращаются в случайные файлы при визуализации.

SD-Card – это рабочий диск ubuntu для моего компьютера orangepi и работает в этот момент.

 **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 

Ubuntu 16.04 выдержка из man dd

 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 также привел к несоответствию, приводит меня к мысли, что у вас есть либо неисправный кабель, либо неисправный носитель (будь то на носителе ввода или на выходе)

Да, вы можете монтировать разделы внутри изображения с помощью kpartx

 sudo apt install kpartx cd Images sudo kpartx -a orangepi.img 

Он будет создавать устройства под / dev / mapper, и устройства должны быть обнаружены nautilus, чтобы их соответствующие разделы были смонтированы.

Чтобы удалить устройство под / dev / mapper, после размонтирования раздела,

 cd Images sudo kpartx -d orangepi.img 

Что касается того, почему раздел отличается в вашем случае, я понятия не имею, что вы сделали, чтобы закончить этот результат. Это должно быть одно и то же.

Я всегда избегаю делать dd на отдельных разделах. За исключением одного и того же носителя, такого же размера, номера модели …

Похоже, вы создали большой раздел на новой карте и что-то испортили с помощью inodes.

Вы сказали, что не можете смонтировать образ, но работает ли он на целевой SD-карте? Должно…

Я предполагаю, вы пытаетесь перейти на более крупную карту. Мой предпочтительный способ – это полная карта. Затем загрузитесь в режиме реального времени или подключите другой компьютер, загрузите Gparted, сжимайте раздел из нескольких MB, а затем вернитесь в полный размер. Он восстановит новое свободное пространство и займет всего 2-3 минуты.

Даты и размеры файлов .xsession-errors полностью различаются между двумя списками файлов на вашем снимке. Нет никакого способа, чтобы «dd» смог это сделать без скремблирования всей файловой системы до неузнаваемости.

Вы не должны использовать dd для смонтированных файловых систем. Это трудно избежать, когда большинство систем автоматически монтируются, как только вы включаете SD-карту.

Используйте «df» и «dmesg», чтобы найти / dev / sd_ # вашей SD-карты. Предупреждение: на этой SD-карте может быть более одного, если на нем есть несколько разделов.

 sudo umount /dev/sd_# 

чтобы размонтировать SD-карту, но она все равно будет подключена и не будет выбрана.

Запустите 'df' еще раз, чтобы проверить, что он был размонтирован.

Теперь вы можете «dd» читать или записывать на SD-карту в целом (первая пара оригинального плаката «dd»).

Скажите системе, чтобы извлечь SD-карту. [В Ubuntu 16.04 щелкните правой кнопкой мыши на SD-карте и выберите «Извлечь родительский диск». Они действительно должны добавить опции «mount» и «unmount»]. Если вы не можете найти параметр Eject, запустите «sync» и дождитесь, пока запрос вернется, чтобы сбросить буферы записи до удаления SD-карты.

У карты SD могут быть плохие блоки.

'sudo badblocks -s -w / dev / sd #' на SD-карте назначения для запуска теста шаблона режима записи. Будьте осторожны с / dev / sd #. «badblocks -w» ДЕСТРУКТИВНО! Вы можете проверить / dev / sd # на «ls -l / dev / disk / by-id /», чтобы убедиться, что у вас есть правильное блочное устройство.

Я запускаю это на всех своих новых устройствах хранения и любых подозрительных плохих. 1 ТБ SATA HDD занимает около 24 часов, чтобы завершить один проход из четырех моделей. Карта SD будет значительно быстрее. Таким образом, я нашел плохие USB-флешки, SD-карты, жесткие диски и даже несколько плохих USB-микро-SD-карт.

Если появятся какие-либо плохие номера блоков, вы можете попробовать RMA устройство, если оно все еще находится под гарантией.