No campo, eu preciso que alguns usuários consigam fazer arquivos iso de forma confiável a partir de um cdrom que também esteja servindo como um LiveCD montado e, portanto, criei um caso de teste manual antes de fazer qualquer script. O caso de teste falha.
Procedimento de teste de duplicação ISO
Para ser específico, o procedimento de teste manual é:
- comece com um arquivo iso de um
LiveCdd particular personalizado baseado em ubuntu-9.10
- gravar um cd usando este arquivo iso com o gravador # 1 do computador
- boot cd com o computador # 2 - após a inicialização, certifique-se de que / tmp tem capacidade suficiente para armazenar uma cópia da iso
- use dd no computador # 2 para criar outro arquivo iso em / tmp
- verifique o tamanho do arquivo e o md5 da iso resultante em / tmp
com o originalmente usado na etapa
Falha do caso de teste
O modo de falha quando a cópia não foi concluída.
O Burner era um desktop Gateway rodando o Brasero no Ubuntu-9.10
O Booter era um laptop ASUS N.
df identifica o cdrom como / dev / sr0
/ tmp mostra muito espaço para manter a imagem
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 ....
O tamanho iso original é 523497472 bytes, portanto, cerca de 127 k está faltando.
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
Pensamentos? Existem algumas opções menos óbvias que eu deveria estar dando dd no caminho de tamanhos de bloco ou dizendo-o para reler em erro?
** Atualização * é bem-sucedida no VirtualBox
Executou outro exercício de cópia - desta vez do SUN VirtualBox em vez de hardware físico. Isso testaria parcialmente, por exemplo, se o próprio arquivo iso era o culpado ou se havia algo de peculiar em termos de software. O dd funcionou bem para recriar o iso quando o liveecd rodava no hardware virtual na medida em que os tamanhos físicos coincidiam e o md5 combinava.
Update # 2 O cdrom isolinux.bin e md5sum.txt FAIL md5 quando lidos do computador # 2 após a inicialização.
Execute md5sum -c md5sum.txt no arquivo de soma md5 do CD.
Nenhum dos acessos a arquivos se queixou de não conseguir ler o dispositivo.
Eu esperava que um arquivo próximo ao final da gravação tivesse problemas.
O isolinux.bin md5 e o md5sum.txt md5 não coincidem. O isolinux.bin é o código de inicialização usado na inicialização do sistema para carregar o kernel do linux e o initrd - e funcionou bem. O arquivo md5sum é, bem, o arquivo md5sum para verificar o conteúdo do cd. Dos arquivos que poderiam ter sido corrompidos, isso é um par estranho em termos de segurança. Mas existem apenas 12 arquivos no CD. Se isolinux.bin está corrompido, como ele ainda inicializou ok? Estranho.
Verificando o sistema de teste do VirtualBox, onde a duplicação da iso foi bem-sucedida, descobri que o md5 para isolinux.bin e md5sum.txt não correspondia ao arquivo md5sum. Os md5 reais também correspondem exatamente aos que são lidos no computador físico. Isso pode simplesmente significar que o arquivo md5sum foi gerado antes que o isolinux.bin fosse finalizado ou que um novo isolinux.bin fosse copiado após o md5sum ser feito.
Observe que não houve reclamações sobre a impossibilidade de ler blocos de arquivos ao passar pelo sistema de arquivos.
Wikipedia vs dd
A interação com Richard T levou-me a pensar na confiabilidade básica do cdrom. A entrada wikipedia para iso9660 fala sobre um CDROM Mode 1 que inclui 288 bytes de código de correção de erros para cada 2048 bytes de dados do usuário . Para que o dd produza uma cópia fiel, ele precisa ter tudo correto sem o benefício do ECC? Se o ECC fizer parte da especificação iso9660, eu diria 'sim' porque o dd está copiando os bits ECC e os dados sem considerar o uso de um para influenciar o outro. Se o ECC fizer parte do driver de CD-ROM / dev / sr0, eu diria 'não'.
Se a única maneira de obter a cópia corrigida por erro é percorrer o sistema de arquivos, então eu precisaria usar genisoimage e pegar os primeiros setores com dd para dar a genisoimage os setores de boot de volta, eu acho. Ainda esperando por algo da mente do grupo.
genisoimage
Tenho sorte de ter o comando genisoimage original para dominar o arquivo iso original.
Então, do computador 2, executando o LiveCD, eu tentei. Isso não é suficiente, mas talvez nos aproximemos.
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.
Pelo menos agora sabemos porque o md5 no isolinux.bin não combina - genisoimage quer fazer algo com isso!
Um ataque feio
OK, então a próxima coisa a fazer foi criar um diretório chamado uglyhack e ligar simbolicamente todos os arquivos do / cdrom, exceto o isolinux.bin, que obtém uma cópia real. genisoimage leva isso, e escreve 0MB sem mensagens de erro. Acho que o genisoimage ignora arquivos com links simbólicos.
A boa notícia é que isso sugere uma resposta, mas não muito bonita:
copie todos os arquivos do / cdrom para outro sistema de arquivos gravável e execute o genisoimage nele.
E agora?
Deve haver uma maneira melhor de realizar essa tarefa.