Копирование SD-карты с помощью dd не копирует точно
Я пытаюсь сделать копию своей SD-карты, таким образом, я могу переместить ее в свою SD-карту на 64 ГБ. Я сделал это с SD-картой Raspberry Pi, никакие проблемы там.
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-карты?
Домашняя папка моей SD-карты имеет папку под названием Музыка, содержащая папки с mp3 файлами.
Мое изображение имеет x-font.ttf с именем Музыка. Папки, кажется, изменяются в случайные файлы при обработке изображений.
SD-карта является рабочим диском 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 просто имеет суммы md5 и sha.
6 ответов
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) Сбойная область на диске, где вы сохранили изображение. Это подразумевает надвигающуюся неисправность накопителя (надеюсь, у вас есть резервные копии, если нет, прыгайте на него!) Было бы разумно проверить интеллектуальное состояние диска, на котором вы сохранили изображение.
Тот факт, что dcfldd также привел к несоответствию, заставляет меня полагать, что у вас есть либо неисправный кабель, либо неисправный носитель (будь то на носителе ввода или на выходе)
Да, Вы можете монтировать разделы в изображении с помощью kpartx
sudo apt install kpartx
cd Images
sudo kpartx -a orangepi.img
, Оно создаст устройства под/dev/mapper, и устройства должны быть обнаружены наутилусом, чтобы позволить их соответствующим разделам быть смонтированными.
Для удаления устройства под/dev/mapper, после размонтирования раздела,
cd Images
sudo kpartx -d orangepi.img
относительно того, почему раздел отличается по случаю, я понятия не имею, того, что Вы сделали для окончания с тем результатом. Это должно было быть то же.
Я всегда стараюсь не делать dd на отдельных разделах. За исключением точно того же носителя, того же размера, номера модели...
Похож на Вас, создал больший раздел на новой карте и смешал что-то с inodes в процессе.
Вы сказали, что не могли смонтировать изображение, но оно работает, как предназначено над целевой SD-картой? Это должно...
я возьму предположение, Вы пытаетесь переместиться в большую карту. Моим предпочтительным путем является dd целая карта. Затем начальная загрузка на живом или включает другой компьютер, загружает Gparted, уменьшает раздел пары МБ, затем обратно к полному размеру. Это освободит новое свободное пространство и занимает только 2-3 минуты
.xsession-ошибочные даты файла и размеры полностью отличаются между двумя списками файлов в Вашем изображении. Нет никакого пути 'dd', сможет сделать это, не скремблируя целую файловую систему до неузнаваемости.
Вы не должны использовать dd в смонтированных файловых системах. Это довольно трудно избежать, когда большинство систем автомонтируется, как только Вы включаете SD-карту.
Использование 'df' и 'dmesg' для нахождения/dev/sd_# SD-карты. Предупреждение: может быть больше чем один для той SD-карты, если у Вас есть несколько разделов на ней.
sudo umount /dev/sd_#
для размонтирования SD-карты но это будет все еще соединено и не извлечено.
Выполнение 'df' снова для проверки его было размонтировано.
Вы можете теперь 'dd', чтобы читать или записать в SD-карту в целом (первая пара исходного плаката 'dd').
Говорят системе извлекать SD-карту. [В Ubuntu 16.04 щелкните правой кнопкой по SD-карте, и выбор "Извлекают родительский диск". Они действительно должны добавить, "монтируют" и "размонтировали" опции], Если Вы не можете найти опцию Eject, выполнить 'синхронизацию' и ожидать подсказки для возврата для сбрасывания буферов записи перед удалением SD-карты.
SD-карта может иметь поврежденные блоки.
'sudo badblocks -s -w / dev / sd #' на целевой SD-карте, чтобы запустить шаблонный тест режима записи. Будьте очень осторожны с / dev / sd #. 'badblocks -w' УЖАСНО! Возможно, вы захотите проверить / dev / sd # против 'ls -l / dev / disk / by-id /', чтобы убедиться, что у вас правильное блочное устройство.
Я запускаю это на всех моих новых устройствах хранения данных и любых подозреваемых плохих. Жесткий диск SATA емкостью 1 ТБ занимает около 24 часов, чтобы выполнить один проход из четырех шаблонов -w. SD-карта будет значительно быстрее. Таким образом, я нашел плохие USB-флешки, SD-карты, жесткие диски и даже несколько плохих USB-картридеров micro-SD.
Если появятся какие-либо номера блоков с ошибками, вы можете попробовать RMA-устройство, если оно все еще находится на гарантии.
Это - комментарий, как хрупкие микросхемы SD/microSD могут быть.
Я использовал вышеупомянутый комментарий о badblocks для тестирования 2 новых микросхем microSD на 512 ГБ. Учитывая их размер, я пошел с картридером USB 3.0 на порте USB 3.0. Микросхемы стали горячими, действительно горячими. Я затем сделал сравнительный тест с помощью Дисков для подтверждения их скорости, с помощью моего стандартного теста 1 000 образцов (а не стандартные 100), снова на порте читателя/3.0 USB 3.0. 1 передал, другой добрался до ~600 образцов и скорости записи, отброшенной от ~90 МБ/с до менее чем 20 МБ/с. Та скорость записи не возвращалась, таким образом, я думаю, что "записал" ^ микросхема из-за питания, доступного на порте USB 3.0.
Учитывая, что badblocks является интенсивным, полным диском, процесс записи-чтения, который занимает много времени, я предложил бы использовать картридер USB 2.0 или предпочтительно картридер USB 3.0 на порте USB 2.0, минимизировать возможность сжигания большой (дорогой) микросхемы. Это займет больше времени, но итак что. Я затем рекомендовал бы использовать стандартные диски 100 образцов для сравнительного тестирования (читатель/USB USB 3.0 3,0 порта).
Я (к сожалению), использовал много меньших микросхем microSD на 128 ГБ для определения вышеупомянутой процедуры. Большинство которых возвратилось под RMA для того, что привело мое тестирование к сбою. Эти микросхемы просто не так устойчивы как даже карты флэш-памяти USB 3.0, таким образом, принцип "качество на риск покупателя".
^ Между прочим, если Вы находитесь на картридере USB 3.0 / порт USB 3.0, и Ваша микросхема берет намного дольше, чем другая микросхема того же размера, это может уже быть "записано".