CentOS 6.3システムベースの製品があります。私たちの機能の1つは、ユーザーがデータをCDROMにエクスポートできることです。いくつかの修正作業の実行中に奇妙な問題が発生しました。 cdrecordの呼び出し直後にディスクをマウントしようとしましたが、mount -o ro /dev/sr0 /mnt/cdrom「マウント：ファイルシステムの種類を指定する必要があります」というメッセージで失敗しました。を使用するとうまく機能mount -t iso9660 -o ro /dev/sr0 /mnt/cdromし、ディスクを取り出して再挿入するとうまく機能します。
少しの調査の終わりに、cdrecordの後（ディスクを取り出してから再挿入するまで）blkid /dev/sr0何も返されませんでしたが、取り出しまたは挿入した後は正しく機能することがわかりました。
これは正常な行動ですか？この問題を引き起こしているCDROMドライブの状態はありますか？サイクルを取り出さずにリセットする方法はありますか？これで、このインスタンスで指定されたファイルシステムの以前の動作に戻って記録します。
バージョン:
mount -V
util-linux-ng 2.17.2でマウントされた（libblkidとselinuxをサポート）
blkid -v
util-linux-ng 2.17.2のblkid（libblkid 2.17.0、2010年3月22日）
cdrecord -version
Cdrecord-yelling-line-to-tell-frontends-to-use-it-like-version 2.01.01a03-dvd Wodim 1.1.9 著作権 (C) 2006 Cdrkit Suite 貢献者 Joerg Schilling の作品に基づく) ) 1995-2006, J. シリング
答え1
さて、今は@derobertのアドバイスに従い、straceを実行する時間がありません（他の作業が待っています）。現在のバージョンでは、呼び出し-t iso9660後にmountコマンドを追加しましたが、cdrecord問題は解決しました。私のソフトウェアがCDのみを書き込むことを考えると、この場合、ファイルシステムはiso9660であると確信しているため、このトリックを無限に回避できます。
答え2
あなたが使用しているプログラムは、元のcdrecordを配布しない欠陥のあるブランチとLinuxディストリビューションからのものです。しかし、2004年5月に作成されたブランチは、最新の機能とバグ修正を達成するためにソフトウェアを更新しませんでした。 "wodim"を配布するディストリビューションは、実際のmkisofsの代わりにgenisoimageなどの他のバグを持つソフトウェアも配布します。
2004年5月の元のmkisofsにも多くのバグがありましたが、2004年のDebian genisoimageには多くのバグが追加されました。
2006年夏、元のソフトウェアで知られているすべてのバグが修正され、元のソフトウェアの機能は2004年5月（使用中のフォークが作成された時点）以来2倍に改善されました。
genisoimageを使用して構造的エラーを含むファイルシステムイメージを作成しました。問題がある場合は、以下から最新のソースソフトウェアにアップグレードすることをお勧めします。
https://sourceforge.net/projects/cdrtools/files/
自動ファイルシステム検出が機能しない場合は、実際のファイルシステムの問題や検出ソフトウェアのバグが原因で発生する可能性があります。
実際のmkisofsで生成されたファイルシステムイメージを確認しても問題が解決しない場合は、検出ソフトウェアのバグレポートを送信してください。