Назад | Перейти на главную страницу

восстановить файл iso из запущенного livecd - dd не будет работать надежно, а в genisoimage есть ловушка-22

В этой области мне нужно, чтобы некоторые пользователи могли надежно создавать iso-файлы с компакт-диска, который также служит в качестве смонтированного LiveCD, поэтому я придумал ручной тестовый пример, прежде чем выполнять какие-либо сценарии. Тестовый пример не проходит.

Процедура тестирования дублирования ISO

Чтобы быть конкретным, процедура ручного тестирования:

  1. начать с iso-файла конкретного настроенного livecd на основе ubuntu-9.10
  2. записать компакт-диск, используя этот iso-файл с записывающим устройством компьютера №1
  3. загрузочный компакт-диск с компьютером №2 - после загрузки убедитесь, что / tmp имеет достаточно места для хранения копии iso
  4. используйте dd на компьютере №2, чтобы создать еще один файл iso в / tmp
  5. проверьте размер файла и md5 полученного iso в / tmp с тем, который был первоначально использован на шаге

Отказ тестового случая

Режим сбоя - копирование не завершено.

Burner был рабочим столом шлюза, работающим под управлением Brasero на Ubuntu-9.10.

Booter был ноутбуком ASUS N.

df идентифицирует компакт-диск как / dev / sr0

/ tmp показывает достаточно места для хранения изображения

dd if=/dev/sr0 of=/tmp/cdtest.iso
dd: reading '/dev/sr0' Input/Output error
1022208+0 records in
1022208+0 records out
523370496 bytes (523 MB) copied ....

Исходный размер iso составляет 523497472 байта, поэтому не хватает около 127 КБ.

dmesg (clipped)
[  694.212395] sr 1:0:0:0: [sr0] Result: hostbyte=DID_OK driverbyte=DRIVER_SENSE
[  694.212401] sr 1:0:0:0: [sr0] Sense Key : Illegal Request [current] 
[  694.212406] Info fld=0x3e67e, ILI
[  694.212407] sr 1:0:0:0: [sr0] Add. Sense: Illegal mode for this track
[  694.212413] end_request: I/O error, dev sr0, sector 1022208
[  694.212416] __ratelimit: 1 callbacks suppressed
[  694.212418] Buffer I/O error on device sr0, logical block 255552
[  694.212419] Buffer I/O error on device sr0, logical block 255553
[  694.212422] Buffer I/O error on device sr0, logical block 255554
[  694.212424] Buffer I/O error on device sr0, logical block 255555
[  694.212426] Buffer I/O error on device sr0, logical block 255556
[  694.212428] Buffer I/O error on device sr0, logical block 255557
[  694.212429] Buffer I/O error on device sr0, logical block 255558
[  694.212431] Buffer I/O error on device sr0, logical block 255559
[  694.212433] Buffer I/O error on device sr0, logical block 255560
[  694.212434] Buffer I/O error on device sr0, logical block 255561

Мысли? Есть ли какие-то менее очевидные варианты, которые я должен указать dd в виде размеров блока или сказать, чтобы он перечитал при ошибке?

** Обновление * Успешно на VirtualBox

Выполните еще одно упражнение по копированию - на этот раз с SUN VirtualBox вместо физического оборудования. Это частично проверит, например, был ли виноват сам файл iso или было что-то особенное с точки зрения программного обеспечения. dd отлично работал, чтобы воссоздать iso, когда livecd работал на виртуальном оборудовании, поскольку физические размеры совпадают и совпадают с md5.

Обновление №2 Изолинукс.bin и md5sum.txt компакт-диска НЕ ​​УДАЛИ md5 при чтении с компьютера №2 после загрузки.

Выполните md5sum -c md5sum.txt в файле суммы md5 на компакт-диске.

Ни один из обращений к файлу не жаловался на невозможность чтения с устройства. Я ожидал, что файл ближе к концу записи будет иметь проблемы.

Изолинукс.bin md5 и md5sum.txt md5 не совпадают. Isolinux.bin - это загрузочный код, используемый при загрузке системы для загрузки ядра Linux и initrd - и он работал нормально. Файл md5sum - это файл md5sum для проверки содержимого компакт-диска. Из файлов, которые могли быть повреждены, это странная пара с точки зрения безопасности. Но на диске всего 12 файлов. Если файл Isolinux.bin поврежден, как он все еще загружается нормально? Странный.

Проверяя тестовую систему VirtualBox, в которой удалось дублировать iso, я обнаружил, что md5 для isolinux.bin и md5sum.txt не соответствует файлу md5sum. Фактические md5 также точно совпадали с теми, которые считывались на физическом компьютере. Это может просто означать, что файл md5sum был сгенерирован до того, как был завершен файл isolinux.bin, или новый файл isolinux.bin был скопирован после создания md5sum.

Обратите внимание, что не было жалоб на невозможность чтения блоков файлов при просмотре файловой системы.

Википедия против dd

Взаимодействие с Ричардом Т. заставило меня задуматься о базовой надежности компакт-дисков. В запись в Википедии для iso9660 говорит о CDROM Mode 1, который включает 288 байтов кода исправления ошибок на каждые 2048 байтов пользовательских данных. Должен ли dd создавать точную копию, чтобы все было правильно без использования ECC? Если ECC является частью спецификации iso9660, я бы сказал «да», потому что dd копирует биты ECC и данные без учета использования одного для влияния на другой. Если ECC является частью драйвера cdrom / dev / sr0, я бы сказал «нет».

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

генизоизображение

Мне повезло, что у меня есть оригинальная команда genisoimage для обработки исходного файла iso.
Итак, с компьютера №2, на котором запущен LiveCD, я попробовал. Этого тоже недостаточно, но, возможно, мы приближаемся.

apt-get install genisoimage
cd /cdrom
genisoimage -r -V "OurLiveCDNameIsSomethingElse" -cache-inodes -J -l -b isolinux/isolinux -c isolinux/boot.cat -no-emul-boot -boot-load-size 4 -boot-info-table -o /tmp/cdcopy.iso .
Output:
...using utf-8 (detected in locale)
Size of boot image is 4 sectors-> No emulation
genisoimage: Read-only file system.  Error opening boot image file './isolinux/isolinux.bin' for update.

По крайней мере, теперь мы знаем, почему md5 на сайте isolinux.bin не совпадает - genisoimage хочет что-то с ним сделать!

Уродливый взлом

Хорошо, поэтому следующим шагом было создание каталога с именем uglyhack и привязка к нему всех файлов из / cdrom, за исключением Isolinux.bin, который получает настоящую копию. genisoimage принимает это и записывает 0 МБ без сообщений об ошибках. Guess genisoimage игнорирует файлы с символическими ссылками.

Хорошая новость заключается в том, что это предлагает ответ, но не очень красивый:
скопируйте все файлы из / cdrom в другую, доступную для записи файловую систему, а затем запустите genisoimage на ней.

И что теперь?

Должен быть какой-то лучший способ решить эту задачу.

Я не эксперт в этой области, но мне кажется, что ваш тест не завершен: пока вы не использовали свой ISO-образ, вы еще не знаете, отсутствуют ли в нем эти 127K. Даже на устройствах CD (и DVD) есть накладные расходы. Ваши ISO-образы представляют собой ЛОГИЧЕСКОЕ представление, а не физическое, и до тех пор, пока их точность не будет доказана, я бы не поверил, что различные инструменты отчетов о дисках предоставляют вам только фактическую информацию о байтах данных - логическую; редко уделяется внимание тому, чтобы сообщить только одно или другое.

Если вы создали соответствующий диск из ISO и сравниваете ISO с ISO, это одно, но пока вы фактически не использовали свой ISO, так что ... вам нужно провести еще несколько тестов. Сделайте диск из полученного ISO и затем сравните ...

RT

ОБНОВЛЕНИЕ: Ой! Глупый я: сначала выясни свою ошибку! Что насчет журнала сообщений? RT

ОБНОВЛЕНИЕ 2: В вашем обновлении говорится об оборудовании, но вы так и не ответили на вопрос: о чем вам пытаются сообщить сообщения об ошибках? Компакт-диски не так безошибочны, как магнитные диски ...