- キット各種完売。
- msBerryDAC改造情報
2008/11/21(金)Canon CAPT プリンタ を x64 Linux で使えない
レーザープリンタが欲しくて、モノクロレーザープリンタを買ったんですが、さんざんな目に合いました。
Canon CAPT プリンタ
CanonのレーザープリンタといえばLISP4とかですが、廉価品のプリンタは CAPT という規格になっています。サーバに付けようと思いまして。
- Ubuntu Server 8.04 LTS (x64/amd64)
- Canon LBP-33xx
「今時Linuxでも何の問題もなく使えるさ」と思ったのが運の尽き、CAPTドライバはx64版が提供されてない(汗) ppdファイルだけ送り込めばなんとかなるかなと思ったもののダメ。
色々調べてみるとドライバソースファイルが提供されていたため、コンパイル作業にいそしみました。エラー多発。
- automake 1.9以降が必要
- libgtk-1.2-devが必要
- cndrvcups-capt-1.70/statusui
gtkを入れる最中に X ライブラリを大量に放り込まれ微妙な気分に……。それでも挫けず、数時間以上かけて、上の謎な対応もしても statusui はコンパイルエラー(致命的エラー)。なおしようがないので statusui を除いてインストール。
raw driver に逃げる
そもそも /dev/usb/lp0 = /dev/usblp0 としてデバイスのポートは見えているので、Windows上でプリンタ用データを生成して直接送り込めばいいということにしました。*3
CUPSをインストールして設定。これまたどうやっても印刷できず。USB認識のタイミングや、接続、デバイスなど何十回とテストしてもうまくいかない。そもそも、Windowsによって生成されたプリンタデータを
dd if=testdata of=/dev/usblp0
しても、20KB送り止まったり、そのあと1byteも送れなくなったり。何をどうやっても、raw プリンターとして認識出来ない。
原因
もう八方ふさがりで十数時間を浪費したあと、さらに多くの情報を漁りながら考えたこと。
- 少なくとも CUPS の filter は無事動作しているのに、印刷できないのはおかしい。
- /dev/usblp0 がそもそもデータを受け付けないのはおかしい。
色々試行錯誤した結果、原因判明。
Canon CAPTプリンタを動作させるにはccpdと呼ばれるデーモンが必要で、これはコンパイル済の状態でしか配布されてない。
ccpd(Canon Common Printer Daemon)を起動することにより、/dev/usblp0 ではない専用の通信路(Canon Printer Deamon Port#x)が表示されます。ここに印刷データを出力することでCanon CAPTプリンタは使用できます。*4
感想
ccpd のソース配れ!*5 というか Canon いっぺん死んでくれ。
さて困ったどうしよう…(汗)
追加調査
ccpd を 32bitバイナリとして実行して(ia32-emulationな環境)みました。色々試行錯誤の上、「captmoncnab7」が起動するところまでこぎ着けましたが、そこで止まりました。
captmoncnab7 は ccpd が起動させているようです。CAPTというプリンタは内部に処理機能をほとんど持っていません。必要な処理はソフトウェア(ドライバ側)で実現しようという思想によるものです。このデーモンは、印刷データをプリンタと双方向通信して実際の印刷処理(プリンタの制御処理)を行うデーモンと予想されます。
どうやら、gs-esp*6との通信に問題があるのではないかと思うのですが……。クローズソース(プロプライエタリ)なドライバではどうにもこうにも。
EPSONとか
EPSONは公式にはLinuxドライバを提供していませんが、サードパーティーからCUPSの本来の形式に則った形でドライバが提供されています。しかもオープンソースで。
Canonはソースの秘匿のためにわざとややこしい仕組みを使っているとしか思えない。なんだかなあ。次買うときはEPSONかな。(ある人おすすめのブラザーもよさそう。……よく見るとトナーとドラムが分離しているので、ランニングコストが安くすみそう。ブラザーいいなあ。*7)
Canonはダメだ
CanonはLinuxで使う分には終わってる気がする。ネットで検索してみると面白いようにトラブル事例がたくさん引っかかる。
後日
2008/10/16(木)Linuxを使ってWindows環境を丸コピー
Windowsを使ってWindowsを丸移植
Windowsを80GBから1TBのHDDに移植(交換)する作業が必要になりました。よくやる手は、
- 新HDDの新しい区画(第1パーティション)を作成し、同じバージョンのWindowsを新規インストール。
- 全く関係ないHDDからWindowsを起動して、旧HDDのCドライブのファイルすべてを、新HDDのCドライブに丸コピー。*1
- 元のマシン(旧HDDが付いていたマシン)に新HDDのみを取り付け、起動。
注意点。
- 新HDDの区画を旧HDDのOS上から決して認識させないこと。
- 新HDDから初めて起動するとき、絶対に旧HDDを接続しないこと。
- 新HDDがCドライブとして認識されるよう注意する。余計なドライブ類やUSBドライブなどがドライブレターとして先に認識されるようなら必ずオフにしておく。
今回もこの方法と行きたかったのですが、両方ともSATAのためできませんでした。原理的には問題ないのですが、家の環境では「SATAで稼働中のWindowsは1台しかない*2」ので無理でした。
Linuxを使ってWindowsを丸移植
- 旧HDD /dev/sda
- 新HDD /dev/sdb
fdiskで旧HDDのパーティーションを確認。
/dev/sda1 1 2123 NTFS
新しいHDDに全く同じサイズのパーティーションを作成。
/dev/sdb1 1 2123 NTFS
ddコマンドで丸コピー。
# dd bs=64M if=/dev/sda1 of=/dev/sdb1
それで、新HDDを差して再起動。……起動しない。もちろん最初に書いた注意点は守ったのに。
ミスの詳細
そういえばMBRを書き込んでなかったと思って、Windows回復コンソールから
C:\>fixmbr
としてもダメ(HDDのブートセクタの復旧というやつです)。その後、色々試しても起動せず、FDからmbmを起動すれば一発解決だったのですが、FDドライブが付いてない。○時間経過。どうにもこうにも困り果てたところで、ふとLinuxを起動して、fdiskを叩いたところで原因発見。
デバイス Boot Start End /dev/sda1 1 2123 Linux
区画番号がLinuxのままだった(汗)
fdiskから、「t」→「7」でNTFSに変更し、Windowsはアクティブ区画からじゃないと起動しないので、「a」→「1」でこの区画をアクティブ(ブートするパーティーション)として設定。
デバイス Boot Start End /dev/sda1 * 1 2123 NTFS
無事、Windowsが起動したのでした。疲れた……(汗)
なぜ回復コンソールにfdiskが入ってないのか、小一時間問いつめたくなった。
2008/05/22(木)Linuxでmdadmを使ったソフトウェアRAIDの構築・管理メモ
Linux(Ubuntu 10.04 LTS Server)で mdadm を使用してソフトウェアRAIDを構築・管理する方法について述べます。特に既に稼働中のLinuxにHDDを追加してあとからRAID1を構築する方法を述べます。
2008/02/14(木)Linux の badblocks コマンド
Linuxでディスクエラーをチェックするコマンドbadblocksについて。
fsck
man。ファイルシステムのエラーをチェックするプログラム。ディスクの物理エラーを調べてはくれない。
# fsck /dev/hda1
badblocks
デバイスそのもののエラーをチェックする。
# badblocks -s -v /dev/hda 読み出しテスト # badblocks -s -v -n /dev/hda 非破壊読み書きテスト # badblocks -s -v -w /dev/hda 破壊読み書きテスト
HDDの区画ではなくHDD全体を与えるのがミソ。破壊テストでは「0xaa, 0x55, 0xff, 0x00」を書き込み読み出してテストします。"-s -v"は進捗などを表示する指定。
一度にテストするサイズは -b(ブロックサイズ)と -c(ブロック数)で指定します。
# badblocks -s -v -b 1024 -c 256 /dev/hda 1024*256
マウントされているディスクでは読み出しテストしかできません。シングルユーザーモードでは読み書きテストができるみたいですが。
非破壊読み書き検査について
非破壊読み書き検査は次の手順で行われます。
- ディスクから現在のデータを読み出す
- ディスクにテストパターンを書き込む
- バッファをフラッシュする
- ディスクから読み込み書き込んだテストパターンと比較する
- 最初に読み込んだデータを書き戻す
Linuxカーネルで「O_DIRECT」というフラグが使えれば、2と4では O_DIRECT 用いてディスクと直接やりとりをします(ディスクキャッシュを抑制します)。これは比較的最近のカーネルでないとまともに使えないようです。
CTRL-Cなどで止めると大変なことになるので、プログラム側でCTRL-Cで落ちないように抑制されています。(上に書いたとおりですので、この検査をkillとかで止めると大変なことになります。)
非破壊テストは破壊テスト並のチェックができますが、単純な破壊テストよりもメモリと時間が食います。
2008/01/12(土)Linuxが止まった
ちょっと他人のサーバのメンテナンスを頼まれて停止したというLinuxを見てきました。比較的古いサーバで /home の使用率が90%を超えていました。おそらくこれが原因だろうと、"du -h" としたらあるディレクトリで動作が止まる。
postmaster
何事だろうと思い、Maildir の中で ls をしてみると
# ls drwx------ postmaster postmaster 512 cur/ drwx------ postmaster postmaster 26123454 new/ drwx------ postmaster postmaster 512 tmp/
ディレクトリファイルが2MBという前代未聞の数値。"ls new/"としたら何分経ってもかえってきません。"rm -rf new/" とすると自動リブート。ディスク容量を食いつぶす以前にファイル数が多すぎてシステムを圧迫するとはあっぱれすぎます。さすがは Linux 2.2 時代の ext2 ファイルシステムです。
仕方ないのでシングルユーザーモードで起動して、ファイルの削除*1を開始したのですが、一向に終わる気配がありません。ざっと概算したら、ファイルの削除だけで2時間もかかることに。メーリングリストのようなシステムに使うメールサーバのpostmasterを数年放置するといかに大変なことがおこるか良くわかりました……。*2
もっともサーバというものは、定期的にチェックかけないと本当は駄目なんですけど、その辺動いてれば気にしないという感じでおざなりにされることが多い。トラブルで困るのは使ってる人なんですけどね……。*3