regenerar o arquivo iso da execução do livecd - o dd não será executado de forma confiável e o genisoimage possui catch-22s

1

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 é:

  1. comece com um arquivo iso de um LiveCdd particular personalizado baseado em ubuntu-9.10
  2. gravar um cd usando este arquivo iso com o gravador # 1 do computador
  3. 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
  4. use dd no computador # 2 para criar outro arquivo iso em / tmp
  5. 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.

    
por user33903 12.02.2010 / 19:59

1 resposta

1

Eu não sou um especialista nessa área, mas parece-me que seu teste está incompleto: até que você tenha usado sua imagem ISO, você ainda não sabe realmente se está faltando esses 127K. Mesmo em dispositivos de CD (e DVD), há sobrecarga. Suas imagens ISO representam uma representação LÓGICA, não uma representação física, e até que se prove com exatidão, eu não confiaria que as várias ferramentas de relatório de disco estão fornecendo apenas as informações reais dos bytes - a lógica; raramente é dado o cuidado de relatar apenas um ou outro.

Se você fez o disco em questão a partir de um ISO e está comparando o ISO ao ISO, isso é uma coisa, mas até agora você não usou o ISO de modo que ... você tem mais alguns testes para fazer. Faça um disco do ISO resultante e faça comparações ...

RT

ATUALIZAÇÃO: Oops! Bobo eu: Investigue seu erro primeiro! E quanto ao log de mensagens? RT

UPDATE 2: Sua atualização fala sobre o hardware, mas você nunca respondeu à pergunta: quais são as mensagens de erro tentando informar? Os CDs não são tão livres de erros quanto os discos magnéticos ...

    
por 12.02.2010 / 17:06