銀杏の木

VMware Player をインストールして使用する場合に、 `Create a New Virtual Machine' から guest OS の iso イメージを読み込み起動しようとしたとき、 modconfig がモジュールを更新しようとするときがある。その際に vmmon のコンパイルのところで止まってしまい実行出来なかった。

止まってしまう原因はいくつかあって、まず、 vmmon, vmnet のソースコードの一部が最近のカーネルと不整合を起こしているためコンパイル時にエラーとなることと、 script の実行時にもエラーが出ること、そして、コンパイルして作成されるカーネルモジュール vmmon.ko, vmnet.ko に署名がされていないため起動に失敗することだ。

まず、カーネルコードとの不整合については、 Michal Kubeček 氏の GitHub に修正版のソース一式を挙げてくださっているので、そちらを使用させていただく。

としてサービスを停止しておいてから、氏の GitHub の INSTALL に記述されている通り、

としてやれば vmmon.ko, vmnet.ko の修正版がインストールされる。（ 14.1.1 のところは使用する VMwarePlayer のバージョンに置き換える。ただし、氏の GitHub に修正版が上がっていることが前提。）

これで vmmon, vmnet のコンパイル時のエラーは解消される。

このとき、 make したとき、

といったエラーも出るが、これは LANG=C make とすることで解消できる。

この後、 make install した後そのまま、

とした場合、

のように２つのモジュールの起動に失敗するが、これは UEFI の validation 機能が有効になっている場合に更新したカーネルモジュールに署名がされていないためなので、

のようにして vmmon.ko, vmnet.ko に署名してやると起動できるようになる。 MOK.priv, MOK.der は事前に作成しキーを登録しておかなければいけない。

VMware が自動的にモジュールを更新しようとしたとき、この署名の操作をしないため、 UEFI の validation が有効になっていると更新に失敗するはずだ。（ VMware はなぜこの問題に対応しないのだろう？ ）

以前から、KiB, MiB などの表記を見かけることはあったが、特に気にせずスルーしていた。

なんとなく気になり検索してみたところが、

なんだそうな。サイトによっては、頭ごなしにこれだけ書いてあったり、サイトによっては、もう少し説明しようとして、人間にとっての「キロ」は１０の３乗だから１０００倍するので、 kB は 1000B なんだと書いてあった。

あのさあ・・・。「バイト」が出てくる時点で、これってコンピュータの世界の単位だって分かるよね？だったら kB = 1000B だなんて思わないと思うんだがなあ。コンピュータの世界で kB つったら、 1024B に決まってると思うし、コンピュータ以外の領域で「バイト」の単位を使う数値を使うことて、まあ、無いよね。

ちなみに、 kiB は、「キビバイト」と読むのだそうな。・・・キビ？きびだんご？

一体どうしてこんな情けない発音の単位が出てきたのか？

Wikipedia を開いてみたら、２００６年に「SI単位系」で、「キロやその他のSI接頭語は、決して２のべき乗を表すために用いてはならない」とかお定めになったからのようだ。「キビバイト」の他にも「メビバイト」「ギビバイト」「テビバイト」「ベビバイト」「エクスビバイト」とか定義なさったらしい。

キロバイト、メガバイト、ギガバイト、テラバイト・・・で慣れ育った身としては、まるでエビか団子みたいな読み方の単位は使いたくないなあ。厳密に正確に・・・というのも必要な場面もあると思うが、それぞれの世界で醸成された文化っていうものも大切にしていただきたいものだ。

こちらのサイト を参考にした。

切替可能な gcc を一覧に登録するには、

とする。ここで、 70 は優先順位を表し、大きい数値ほど優先順位が高くなる。

このとき、同時に、

とすると、 gcc と g++ の２つのリストをそれぞれ別々に管理して別々に切り替えできそうに思うが、これだと g++ の方を設定しようとしたとき、 g++ は gcc のスレーブなのでだめ、と怒られエラーになる。

gcc, g++, gcov のバージョンを連動させて切り替える場合、 g++, gcov は gcc のスレーブなので、

として、連動して切り替わるように設定する。

この状態で、

とすると、切り替え可能な gcc の一覧が表示され、 gcc のバージョンを選択することで、使用する gcc, g++, gcov のバージョンを連動させて選択することができる。

なぜかまた急に無性に Key の「 Air 」を ubuntu で遊びたくなり、やってみた件の続き。

xkanon と wine の２つの方法のうち、 xkanon ( xair ) を使った場合は音が鳴らないので、 wine を使う方法を選んだと前回書いたが、 wine と _inmm で実行した場合、小さなプチプチ音のノイズが乗るので、やっぱり xkanon を使えないかやってみた。

xkanon に実装済みの oss, alsa では正常動作しないので、ソースを眺めながらあれこれいじってみたが、よく分からなかった。そこで、 alsa を使うのはあきらめて、 GStreamer というライブラリを使って音を鳴らすことにして、コードを書き始めた。

GStreamer 用のサンプルコードを試しながら使い方を学習し、 wav ファイルの鳴らし方を理解したので xkanon のソースにコードを組み込み、何度か試して完成させた。 BGM は wav ファイルから鳴らせばよいので CD-DA の実装は行わず、 wav ファイルのみを再生するクラスを作成した。 gst_pipeline_new() でパイプラインを作成し、 filesrc, wavparse, volume, audioconvert, autoaudiosink のエレメントを作成しリンクした。再生中に音量を変化させる方法だけは分からなかったので、 fade out の動作は未実装だ。

今回の作業では GStreamer のもつ柔軟性が感じられた。様々な形式の音源の音をならせられるし、ファイルを読み込んで再生するだけでなく、ネットごしにストリーミング再生もできる。また、音だけでなく動画なども再生する能力を持っている。

なぜかまた急に無性に Key の「 Air 」を ubuntu で遊びたくなり、やってみた。

方法は２つあって、１つ目は JAGARL さんの xkanon ( xair ) を使う方法で、２つ目は wine を使う方法だ。

xkanon を使った場合、 ubuntu 18.04 LTS では音を鳴らすことができなかった。 xkanon は音を鳴らす方法を OSS, ALSA 等から選択できるように作られているのだが、まず OSS は古いものなので今の ubuntu では使用できないため、 ubuntu の kernel をカスタマイズして OSS を組み込んでみたが、 /dev/dsp がそもそも作られなかった。そこで osspd を使用してみたが、 /dev/dsp は作られたものの、音は一切鳴らなかった。そこで、 ubuntu が現在使用している ALSA を使うようにしてみたが、やはり音は鳴らずエラーが出て異常終了してしまう。 xkanon の場合は、音無しでならプレイできるという結果になった。ちなみに、 xkanon の作者の JAGARL さんは配布サイトを閉鎖したようで、現在は作者の配布サイトからソースをダウンロードしたり質問したりすることは出来ない。

そこで、次に wine を使う方法を試してみた。 BGM は CD-DA ではなく _inmm を使い wav ファイルを鳴らすように変更することにした。こちらも最初は音が一切鳴らなかったが、Install GStreamer on Ubuntu or Debian

を見ながら必要なプラグインパッケージなどを全てインストールしたところ、起動時の波の音（効果音）と本編中のセリフ音声は出るようになった。だが、BGMは鳴らず、下の様なエラーメッセージが出続けた。

どうやら、 'audio/x-wav' というメディアタイプに対応する GStreamer のプラグインが見つからないというのだが、理由が分からない。効果音も wav ファイルなのだ。 _inmm 経由で音が再生されるのは BGM だけなので、 _inmm が再生出来ずにいるということしか分からない。

試行錯誤して、やっと解決した方法は、 _inmm.ini ファイルを標準形式ではなく拡張形式で記述し、 [Players] セクションに wav ファイルのプレイヤーを 'MCI = *.wav' という風に MCI を明示することで音がなるようになった。ちなみに、プレイヤーとしては MCI、DirectShow、Winamp、SCMPX、Lilith、Silent（再生しない）から選択できるそうだが、 DirectShow を選択してみたら鳴らなかった。標準形式では何故音が鳴らないかは分からない。