Eu tenho um produto baseado em um sistema CentOS 6.3. Uma de nossas características é que o usuário pode enviar seus dados para um CD-ROM. Ao fazer algumas correções, eu me deparo com um problema estranho - imediatamente após a chamada do cdrecord, nós tentamos montar o disco, porém mount -o ro /dev/sr0 /mnt/cdrom falha com 'mount: você deve especificar o tipo de sistema de arquivos'. Se você usa mount -t iso9660 -o ro /dev/sr0 /mnt/cdrom , funciona muito bem, OU se você ejetar e reinserir o disco, ele funciona bem.
Um pouco de investigação revela o fato de que imediatamente após o cdrecord (e até o disco ser ejetado e reinserido), blkid /dev/sr0 não retorna nada, mas funciona bem depois de ejetar / inserir.
Isso é um comportamento normal? Existe algum estado na unidade de CDROM que causa isso, e há alguma maneira de redefini-lo sem o ciclo de ejeção? Por enquanto estou retornando (e documentando!) O comportamento anterior de especificar o sistema de arquivos nesta instância.
Versões:
mount -V
monte a partir do util-linux-ng 2.17.2 (com suporte a libblkid e selinux)
blkid -v
blkid do util-linux-ng 2.17.2 (libblkid 2.17.0, 22-mar-2010)
cdrecord -version
Linha-de-gravação-de-fala-para-dizer-frontends-to-use-it-like-version-2.01.01a03-dvd Wodim 1.1.9 Colaboradores do conjunto Cdrkit Copyright (C) 2006 Baseado em trabalhos de Joerg Schilling, Copyright (C) 1995-2006, J. Schilling
Bem, eu não tenho tempo para seguir o conselho do @ derobert e correr atrás da coisa neste momento (outras tarefas aguardam). Para a versão atual, simplesmente adicionei -t iso9660 ao comando mount após a chamada cdrecord , o que resolve bem o problema. Dado que o meu software acabou de gravar o CD, posso ter certeza de que o sistema de arquivos é o iso9660, neste caso, para que eu possa me safar com esse truque por um futuro indefinido.
Os programas que você usou são de um fork defeituoso e distribuições Linux que não distribuem o cdrecord original, mas um fork criado em maio de 2004, nunca atualizou o software para obter recursos mais recentes e correções de bugs. As distribuições que enviam "wodim" também enviam outros softwares defeituosos como, por exemplo, genisoimage em vez de um mkisofs real.
Mesmo o mkisofs original de maio de 2004 tinha muitos bugs, mas o genisoimage do Debian adicionou muitos bugs adicionais em 2004.
No verão de 2006, todos os bugs conhecidos foram corrigidos no software original e, desde maio de 2004 (quando o fork que você está usando foi criado), o software original dobrou seus recursos.
A genisoimage que você está usando cria imagens do sistema de arquivos com erros estruturais. Se você tiver problemas, recomendo atualizar para um software original recente de:
Se a detecção automática do sistema de arquivos não funcionar, isso é causado por problemas no sistema de arquivos real ou por um erro no software de detecção.
Se o seu problema não desaparecer quando você verificar com uma imagem do sistema de arquivos que foi criada pelo mkisofs real, por favor, faça um relatório de bug contra o software de detecção.