Как проверить CD и DVD диск после записи

Задача: диск записан - нужно проверить правильность записанных данных.
Решение: для этого есть простые средства, типа dd и md5sum. Реализация в виде скриптов.
Для этого нам нужен md5sum и несколько утилит, входящих в любой уважающий себя дистрибутив. Есть несколько способов, приведу известные мне ниже (если кто предложит ещё - с удовольствием добавлю).

Подсчёт контрольной суммы файла
Для того, чтобы просто подсчитать MD5-сумму уже имеющегося iso-образа, пишем в консольке

md5sum my.iso
Через некоторое время вы увидите что-то вроде этого:

e941bb0ecac20a2043c9f8e69fbab63a my.iso
А можно и так:
cat my.iso | md5sum
Увидите то же самое:
e941bb0ecac20a2043c9f8e69fbab63a
Для скачиваемых из Интернета iso-образов обязательно рядом с ним лежит либо файл MD5SUMS, или такой же по имени файл, только с расширением md5 - не забывайте их скачивать. Так можно будет всегда проверить, правильно ли вы скачали образ диска.
Кстати говоря, кроме метода MD5 встречается SHA1 - его особенно любят федоровцы. Синтаксис тот же, что и у md5sum, только утилита называется соответственно sha1sum.


Проверка правильности записи на CD и DVD диск
Есть несколько способов сделать это, и большинство из них основано на подсчёте контрольной md5-суммы исходного образа и записанного на диск. Их совпадение гарантирует правильность записи и то, что файлы на диске не повреждены.

Способ #1: утилита dd

Эта утилита входит в состав любого дистрибутива и является чрезвычайно полезной во многих случаях - здесь мы тоже будем её использовать. Однако в случае с CD и DVD дисками есть свои тонкие моменты, которые необходимо учитывать, иначе вы получите неправильные результаты.

Для CD-дисков

Вставляем пропаленный диск, и, не монтируя его, пишем в консольке:

dd if=/dev/cdrom | md5sum

Если у вас другое устройство для чтения/записи дисков (не /dev/cdrom) - измените команду соответственно. После выполнения этой команды вы увидите:

$ dd if=/dev/cdrom bs=2048 | md5sum 355562+0 входных записей
355562+0 выходных записей
728190976 bytes transferred in 299,413377 seconds (2432059 bytes/sec)
e941bb0ecac20a2043c9f8e69fbab63a -


Если у вас есть файл MD5SUMS или my.iso.md5 - проверьте, совпадают ли контрольные суммы. Если у вас такого файла нет, но есть образ диска - просто подсчитайте его контрольную сумму, как говорилось выше: md5sum my.iso

Для DVD-дисков
Здесь всё немного сложнее: дело в том, что при записи на DVD пишется так же и служебная информация, поэтому для проверки DVD-дисков утилитой dd нужно точно указывать размер и количество блоков. Для того, чтобы узнать, сколько значимых блоков (extents) имеется в iso-образе, выполняем команду (вводите именно так, как написано, меняя тольк имя образа):

echo $(( $(ls -l my.iso | awk '{ print $5 }') / 2048 ))
Результатом будет число блоков - это число нам потребуется для команды dd:
169383

Теперь, зная, что размер блока равен 2048 байт и количество блоков на DVD-диске, даём команду:
dd if=/dev/cdrom bs=2048 count=169383 | md5sum


Результатом её выполнения будет вывод:
$ dd if=/dev/cdrom bs=2048 count=169383 | md5sum 169383+0 records in
169383+0 records out e941bb0ecac20a2043c9f8e69fbab63a -

Как видно, что записанный на DVD образ и isoшник на жёстком диске совпадают, так что запись прошла успешно.

Подчёркиваю:

для DVD-дисков обязательно нужно указать размер и количество считываемых блоков, иначе утилита dd может считать служебные данные, что исказит значение контрольной суммы и вы будете думать, что запороли болванку в то время как (возможно) данные записаны верно. Более подробно об этом методе говорится, например, здесь.

Пример неправильного подсчёта контрольной суммы: Взяли iso-образ, пропалили его:
growisofs -Z /dev/cdrom=my.iso
Утилита напишет:
builtin_dd: 169392*2KB out @ average 4.4x1385KBps
А теперь считаем данные
dd if=/dev/cdrom | md5sum
169392+0 records in
169392+0 records out
1188f67d48c9f11afb8572977ef74c5e -

Сверяем:
md5sum my.iso:
e941bb0ecac20a2043c9f8e69fbab63a my.iso

Не сходится! А всё почему? Потому, что
утилита dd считали все блоки (169392), как вы её и просили. Но это неправильно: значащих блоков там меньше (169383), поэтому контрольная сумма совсем другая. Всегда указывайте количество и размер блоков при проверке DVD-дисков!


Способ #2: утилита diff
Другой способ, не требующий наличия программы md5sum, был предложен здесь же, в комментариях. Заключается он в остроумном использовании команды diff, которая выдаёт информацию обо всех файлах, в которых совпадает содержимое. Для этого нужно смонтировать только что записанный диск:
mount -t iso9660 /dev/cdrom /mnt/cdrom
и (в другую точку монтирования, на петлевое устройство) имеющийся iso-образ.
sudo mount -t iso9660 my.iso /mnt/flash/ -o loop
Затем напишите
diff -urN /mnt/cdrom /mnt/flash
Если утилита ничего не напишет - значит, все файлы совпадают и запись диска проведена правильно. Это работает и для CD, и для DVD-дисков.


Способ #3: утилита readcd (только для CD-дисков) Эта утилита входит в комплект cdrtools и производит посекторное чтение данных с диска. Очень удобно как для проверки, так и для сдирания образа с какого-нибудь принесённого диска. По этому поводу мной написан простенький скрипт на баше:

#! /bin/sh
if [ -z $1 ]; then
echo "Скорость считывания?"
read kmvISOspeed;
else
kmvISOspeed=$1;
fi
readcd dev=ATAPI:0,0,0 speed=$kmvISOspeed f=temp.raw;
md5sum temp.raw
Некоторые пояснения к скрипту. Для того, чтобы выяснить адрес для ATAPI, запускаем
sudo cdrecord -scanbus dev=ATAPI
Выдаст он нам что-то вроде:

Cdrecord-Clone 2.01.01a01 (i686-pc-linux-gnu) Copyright (C) 1995-2004 Joerg Schilling NOTE: this version of cdrecord is an inofficial (modified) release of cdrecord and thus may have bugs that are not present in the original version. Please send bug reports and support requests to . The original author should not be bothered with problems of this version. cdrecord: Warning: Running on Linux-2.6.15.7 cdrecord: There are unsettled issues with Linux-2.5 and newer. cdrecord: If you have unexpected problems, please try Linux-2.4 or Solaris. scsidev: 'ATAPI' devname: 'ATAPI' scsibus: -2 target: -2 lun: -2 Warning: Using ATA Packet interface. Warning: The related Linux kernel interface code seems to be unmaintained. Warning: There is absolutely NO DMA, operations thus are slow. Using libscg version 'ubuntu-0.8ubuntu1'. cdrecord: Warning: using inofficial version of libscg (ubuntu-0.8ubuntu1 '@(#)scsitransp.c 1.91 04/06/17 Copyright 1988,1995,2000-2004 J. Schilling').
scsibus0:

0,0,0 0) '_NEC ' 'DVD_RW ND-3550A ' '1.05' Removable CD-ROM

0,1,0 1) *

0,2,0 2) *

0,3,0 3) *

0,4,0 4) *

0,5,0 5) *

0,6,0 6) *

0,7,0 7) *
Выделенные полужирным цифры и подставляем в качестве цели для записи - это наш привод.

Резюме
Приведённые способы (в порядке их предпочтительности) позволяют проверить, правильно ли прошла запись на болванку. Этой информации должно хватить для выполнения данной задачи. Но если кто может предложить другие способы - комментарии всегда открыты.

33 комментариев: |высказаться!| RSS-лента дискуссии.|
Unknown комментирует...

Единственная проблема, что md5 уже считается ненадёжной. У себя на FreeBSD я использую sha256, хотя конечно, никогда не натыкался на случаи совпадения MD5 у разных файлов.

virens комментирует...

2 jankkhvej
Единственная проблема, что md5 уже считается ненадёжной.
Для шифрования банковских транзакций в электронных платежах - да. Но ведь тут скачивание файлов. Смысл? :-)

Анонимный комментирует...

А если просто попробовать переписать данные с диска на комп? так нельзя разве проверить?

virens комментирует...

2 kri
А если просто попробовать переписать данные с диска на комп?
Ну да, можно. А как "переписать с диска на комп" загрузочный LiveCD? И чем проверить правильность записи его? Вот тут-то нам эти способы и помогают. И потом проще и быстрее: в скрипт завернул и забыл.

Анонимный комментирует...

Понятно.

Unknown комментирует...

Насчёт смысла md5 и sha256

Честно говоря, не знаю, что там сечас используют для шифрования банковских транзакций, но то, что дистфайлы во фре имеют две контрольные суммы, MD5 и SHA256 - факт.
И потом я тут тесты сделал простые:

CPU: Intel(R) Pentium(R) 4 CPU 3.00GHz (2992.72-MHz 686-class CPU)
Origin = "GenuineIntel" Id = 0xf49 Stepping = 9
Features=0xbfebfbff<FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,C
MOV,PAT,PSE36,CLFLUSH,DTS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,PBE>
Features2=0x641d<SSE3,RSVD2,MON,DS_CPL,CNTX-ID,CX16,<b14>>
AMD Features=0x20100000<NX,LM>
AMD Features2=0x1<LAHF>
Logical CPUs per core: 2
real memory = 1073676288 (1023 MB)
avail memory = 1037393920 (989 MB)

solik@solik$ md5 -t
MD5 time trial. Digesting 100000 10000-byte blocks ... done
Digest = 766a2bb5d24bddae466c572bcabca3ee
Time = 4.021527 seconds
Speed = 248661776.079997 bytes/second
solik@solik$ sha256 -t
SHA256 time trial. Digesting 100000 10000-byte blocks ... done
Digest = 3f7daf2b36997b6eb269f63176e09fee8f6daa13202d87e020da63d262c6a4ca
Time = 15.460602 seconds
Speed = 64680535.240904 bytes/second

4 и 16 секунд - разница огого, особенно если считать суммы образов iso. Но если подсчёт идёт непосредственно с DVD/CD - смысл одинаков, скорость всё равно ограничена железом.

virens комментирует...

2 jankkhvej
Насчёт смысла md5 и sha256
Ого! Спасибо огромное - прямо целое исследование! Обязательно включу в пост при следующей правке! Как говорится, приходите ещё :-)

Анонимный комментирует...

большое спасибо за статью - очень помогла! =)

Анонимный комментирует...

Если диск не загрузочный и нужно просто прогнать файлы, получить их контрольные суммы или просто проверить читаемость и нет желания копировать все на веник - можно воспользоваться find. Что-то типа:
find /cdrom/ -exec md5sum {};
Вместо md5sum можно поставить любую программу. Можно поиграться с фильтрами, чтобы проверять читаемость отдельных файлов.

Анонимный комментирует...

для cdrom и dvd можно так же использовать cat:
например cat /dev/cdrw | md5sum

Анонимный комментирует...

или даже так
md5sum /dev/cdrom

Анонимный комментирует...

Как оказалось метод "в лоб" проверки md5 для CD или DVD работает не всегда правильно (и не на всех приводах). Правильное и проверенное решение здесь http://www.troubleshooters.com/linux/coasterless.htm#rawread

virens комментирует...

Ну да, эти и перечисленные в статьях методы - вариации на тему. Главное, чтобы люди не падали в обморок, если у них не сойдутся md5-суммы для DVD. Кстати, сам по началу так и делал :-)

Анонимный комментирует...

Еще можнго использовать qpxtool (http://qpxtool.sourceforge.net), которая вам выведет график скорости чтения поверхности диска, а так же проведет еще ряд тестов. Очень полезно тем, что иногда в скорости чтения бывают заметные пробелы, и по ним можно судить о надежности компакт диска.

А еще, я где-то читал, что CD и DVD надо проверять через несколько дней после записи, да и потом регулярно, раз в несколько месяцев, так как иногда они имеют свойство портиться. Это конечно стоит делать для важных данных, но лучше тогда их вообще дублировать.

virens комментирует...

2 Alexander Artemenko
Еще можнго использовать qpxtool (http://qpxtool.sourceforge.net), которая вам выведет график скорости чтения поверхности диска, а так же проведет еще ряд тестов.
Спасибо, очень интересная программа, но она проводит тесты дисков - а тут нужна проверка идентичности того, что записывалось, и того, что записалось.

А еще, я где-то читал, что CD и DVD надо проверять через несколько дней после записи
Обычно это свойственно низкосортным болванкам и CD/DVD-RW. На них лучше важную информацию не хранить вообще. Всё важное, безусловно, записывается на 2-3 болванки.

bok комментирует...

Проверял скаченные образы Дэбейна и один из них на md5sum debian-40r1-i386-CD-14.iso выдал нижеследующее
md5sum:debian-40r1-i386-CD-14.iso: Input/output error
Видно что образ подпорченный. но что примечательно большинство файлов из него в норме. В самой ISO`шке присутствует файл md5sum.txt в котором есть контрольная сумма на каждый файл диска.
Может кто подскажет существует ли простой способ увидеть какие из файлов порченные или их не хватает, чтобы не перебирать вручную каждый?

Анонимный комментирует...

Вообщем блесну:
md5, sha - хэш функции, чаще используются для проверки, и из гих сложно получить оригинал. sha - вычислительно сложнее.
т.е. надежность здесь нужны только если вы подозреваете что в дистрибутив что-то встроил злоумышленник.
Для md5 и sha - доказана ненадежность.
для чисто проверки на ошибки копирования используются контрольные суммы, например crc32 - очень быстрая весчь(файлы sfv). (сейчас может имеет смысл использовать crc64) - пакет cksfv.

Анонимный комментирует...

Записывал 3 dvd-видеодиска с одного iso-шника, чексум по Вашему первому варианту у меня оказался провальный. Причём чексум всех 3х дисков идентичен, диски ессно читабельны. Думаю дело в числе блоков, точнее в вычислении его скриптом echo $(( $(ls -l my.iso | awk '{ print $5 }') / 2048 )). Проверил диск утилитой cdck, который в конце мне сказал количество блоков 2046256 (Ваш скрипт написал о iso-шнике 2046177). После повторения операции с dd с указанием количества блоков от cdck чексум совпадает. Вы можете это объяснить?

Анонимный комментирует...

Пордон, всё-таки не совпадают. Кстати, если записать диск меньше 1 Гб, то сумма совпадает. Что могло быть не так?

Анонимный комментирует...

ответ на поставленный мной вопрос оказался довольно прост. Захожу на папку с дебейном св /mnt/cdrom/ и ввожу md5sum -c md5sum.txt и в получаемом консольном выводе разу видно по надписям все нормальные "-OK".
Создать такой файлик тоже просто, лишь в каталоге будущего диска ввести "find .>md5sum.txt".
Метод хорош для детальной сверки целостности каждого файла, хотя он и более медлителен.

Анонимный комментирует...

Если надо убедиться, что все файлы считываются, то:

cp -rf /mnt/cdrom temp.dir

Микола комментирует...

Кстати, утилита dd уже правильно считает контрольную сумму для записанной болванки без указания размеров блока.

Команды

dd if=/dev/cdrom | md5sum

и

md5sum ./image.iso

для записанной болванки и её образа на винте дают одинаковый результат.

Анонимный комментирует...

Столько способов для такого простого действия. Большое спасибо автору статьи и всем остальным. Помогло даже мне :)

alex комментирует...

Немного не по теме, но к вопросу о контрольных суммах.
Создадим директорию
$mkdir samedir

В ней создадим файл
$touch samefile

Теперь создадим образ iso из полученной директории
$genisoimage -R -J -o sameiso.iso samedir

И посчитаем для созданного образа контрольную сумму
$md5sum -b sameiso.iso

Так вот, если две последние команды выполнять несколько раз подряд, то контрольные суммы все время получаются разные.
Когда заметил первый раз, подумал, образ кривой получился.
Потом увидел, что контрольная сумма все время меняется.
Подозреваю, что как-то связано с системными часами, но отчего конкретно зависит - не пойму.
Можно ли как-то сгенерировать два образа с одинаковыми контрольными суммами? Ведь тот же jigdo тоже генерирует iso из файлов, однако контрольная сумма совпадает с заданной.

alex комментирует...

Отвечу сам себе.
Да, действительно, в образе iso присутствует информация о времени создания. Это видно в дампе, а также указано в описании стандарта.
Поэтому сгенерировать два образа с одинаковой контрольной суммой так просто не удастся. В общем-то, это и не нужно. Просто нужно понимать, почему контрольные суммы отличаются.

Добавлю от себя несколько слов о проверке контрольных сумм при записи образов DVD. Я рассматриваю случай, когда команды вводятся вручную, без использования скрипта.
При проверке с помощью команды dd данные подаются на вход md5sum, таким образом, посчитанные контрольные суммы приходится сверять визуально, что не очень удобно.
Я воспользовался таким способом:
1. Создаем файл-очередь

mkfifo /tmp/disk1.fifo

2.Создаем образ для записи на диск. Здесь предполагается, что файлы для записи помещены в одну папку disk.

genisoimage -R -J -o - disk | tee /tmp/disk1.iso >/tmp/disk1.fifo &

md5sum -b /tmp/disk1.fifo >/tmp/disk1.md5

первая команда генерирует образ и направляет данные на вход команды tee, которая перенаправляет их на два потока: в iso-файл и в файл очередь, откуда они попадают на вход md5sum. Генерируется образ и одновременно подсчитывается контрольная сумма.

3. Далее записываем образ на болванку любым удобным способом.
После записи болванки необходимо проверить контрольную сумму.
4. Получаем количество значащих блоков для проверки
ll --block-size=2048 /tmp/disk1.iso
5. Используем dd для считывания данных с диска
dd if=/dev/sr0 bs=2048 count=количество_блоков of=/tmp/disk1.fifo 2>/dev/null &
md5sum -c /tmp/disk1.md5
Получаем стандартное сообщение md5sum

/tmp/disk1.fifo ЦЕЛ

Преимущество данного варианта в том, что для проверки контрольной суммы можно использовать md5sum стандартным способом. На экран не выводится лишних сообщений и нет необходимости дополнительно сравнивать контрольные суммы с диска и из файла.

Анонимный комментирует...

Как восстановить исходный .iso-образ из которого был записан DVD, так чтобы даже сошлись суммы md5? Просто взять и создать .iso-образ не получаеться, суммы разные....

alex комментирует...

[b]Как восстановить исходный .iso-образ из которого был записан DVD, так чтобы даже сошлись суммы md5?[/b]

Я чуть выше писал, что в iso-файле содержится временной штамп - дата и время создания. Этого достаточно, чтобы суммы не сошлись. Поэтому стандартными средствами, скорее всего, не получится.

Можно попытаться залезть в потроха DVD-диска и вытащить информацию из спец. полей, а потом внести соответствующие изменения в iso-файл...
Только стоит ли оно того?

Иван комментирует...

если нужна gui оболочка для вычисления контрольных сумм я пользуюсь
http://gtkhash.sourceforge.net/
там все просто
выбрал файл
нажал кнопку получил ответ

Анонимный комментирует...

Да, автором описаны методы, имеющиеся на 2006 год как понимаю, и выглядят они конечно очень извращенно:) Прочитав их я ушел искать другой способ, современный:) Нашлась программка cdshot, сама крохотная, установки не требует, запускаете, указываете привод, ждете пару минут, получаете все необходимые контрольные суммы. Есть один нюанс, для корректной работы нужно чтобы проводник не был запущен, то есть что бы никакие папки не были открыты, иначе программа выдает ошибку. Поэтому создайте ярлычек на рабочем столе и через него запускайте

virens комментирует...

@Анонимный комментирует...
Да, автором описаны методы, имеющиеся на 2006 год как понимаю, и выглядят они конечно очень извращенно
О да, одну команду в консоли написать - это надо быть доктором наук. Это только для избранных.

Прочитав их я ушел искать другой способ, современный Нашлась программка cdshot
Анонимус... я даже не знаю, что на это сказать. Ну, понятно, что пост мы не читаем (хотя он на русском), но на название блога-то можно глаза поднять!?

Эт чё такое-то:

cdshot.exe 1.64 MБ (1 723 904 байта)

под винду, да!? Ну и методы, в скотлент-ярде! :-)
Ты абсолютно беспощаден, Анонимус, я тебе вот что скажу.

сама крохотная, установки не требует

БЛОГ ПРО ЛИНУКС, мать его за ногу! ;-) И куда крохотнее-то?

-rwxr-xr-x 1 root root 22K 2007-01-31 05:51 md5sum

-rwxr-xr-x 1 root root 38K 2007-01-31 05:51 dd

60Кб на всё. Так что идите-ка вы со своими "современными" методами и "современными" системами по добру по здорову....

Анонимный комментирует...

Спасибо, ваша статья очень помогла. Диск, к счастью, записался нормально. хотя у меня были серьёзные сомнения

prime_k комментирует...

Есть ещё классная программка dvdisaster, есть в репозитории debian. Она графическая, может считывать контрольные суммы образов, сравнивать, проверять качество записанных дисков. Попробуйте.

Unknown комментирует...

попробовал проверить сд с записанным на него systemrescuecd4.5.1 .Выходит,что сд лучше по приведенной методике для двд. ошибки скорей всего от плохого кач-ва сдшек.dmesg выдавал end_request: I/O error, dev sr0, sector 866300. Проверил dd старый записанный alkid на сд, ошибок вв\вывода не было,dmesg спокоен и метод для сд сработал, .Linm@linm-desktop:~$ umount /dev/cdrom
linm@linm-desktop:~$ sudo dd if=/dev/cdrom | sha1sum
dd: чтение «/dev/cdrom»: Ошибка ввода/вывода
866296+0 записей получено
866296+0 записей отправлено
скопировано 443543552 байта (444 MB), 97,8822 c, 4,5 MB/c
dc90448649068d17e66e205400532cf980dea291 -
linm@linm-desktop:~$ dd if=/dev/cdrom bs=2048 count=216573 | sha1sum
216573+0 записей получено
216573+0 записей отправлено
скопировано 443541504 байта (444 MB), 98,1283 c, 4,5 MB/c
93e689d218f412d0096da26053ea9828aa5dc7b6 -
linm@linm-desktop:~$ cd ~/Загрузки/ && sha1sum *.iso
93e689d218f412d0096da26053ea9828aa5dc7b6 systemrescuecd-x86-4.5.1.iso
linm@linm-desktop:~/Загрузки$ echo $(( $(ls -l *.iso | awk '{ print $5 }') / 2048 ))
216573

после этого проверил dd старый записанный alkid на сд, ошибок вв\вывода не было,dmesg спокоен и метод для сд сработал

Отправить комментарий

Подписаться на RSS-ленту комментариев к этому посту.