晴れた日には運河で昼寝

先日「Raspberry Pi で録画システムを構築してみたけれど」というエントリを作りましたが、その後いろいろ模索したあとでとりあえず安定して録画できるようになりました。

おそらく、不安定さは録画ファイルを保存する領域にしていたストレージをUSBメモリにしていたんですけど、そのメモリがそれほどUSB3ではあるもののあまり早いものではなかったので書き込みが追い付かず、1chなら問題ないけど多ch同時録画になると保存が追い付かなかったんだろうなと推測。代わりに古いけどそこそこのHDDに変えたところ安定して保存できるようになりました。

その後、テスト運用を続けていますが、変更後ここまでは多ch録画で処理が追い付かないことが原因と思しき不安定さは出ていません。

一点だけ、おそらくEPGがらみで番組情報がややこしいものになっているものっぽい番組予約は、今でも0KBのファイルが出来上がっていることがあるんですよね・・・（NHKの「あさイチ」）、国会中継とか入っているときの「あさイチ」は十割0KBでした。

おそらくこれはChinachu+Mirakurunの問題なんだろうなぁ・・・。

先の週末、手元にあるRaspberry Piに用途が定まっていないものがあるので、Chinachuを使って録画システムを構築したみた。

とりあえずMirakurunとChinachu構築が終わって動くようになったけど、どうにも動作が不安定で困ってる・・・。

はじめは1ch～2chだけ視聴とか録画は問題なくて3ch以上同時に録画しようとするとデータの取りこぼしが発生する状況だったけど、今は1chだけでもダメな感じ。映像は真っ黒で音声が途切れ途切れな状況に。

多ch同時録画で処理が追い付かない状況でもなさそうだし、どこがおかしいのかな？

調べた結果、NP12に乗っているNICの蟹チップが使わない方が良いものであるらしいことが分かった。ということでオンボードのNICは諦めてUSBのNICを用意してそちらを使うことにした～

色々使おうと調べたりしたんだけど、手間に見合うリターンが得られそうにないのです。

あと、NICの件とは別にNP12のAtom 230がとても動作がもっさり・・・。
Atom 330のマシンはそれなりに動作するんだけどね～。

【追記】
タイトルにはDebian Busterってありますが、試行錯誤の中で実際に試したのはUbuntu 16.04をアップグレードしたUbuntu 18.04でした。

友人某O氏から以前ネット上にサーバとして利用していたEPSON Endeavor NP12という今となってはとても古い超小型PCを譲ってもらったんですよ。

PCの中の160GBのHDDを500GBのSSDに交換して、Debianをインストールしたんですが、インストールの途中で存在しているはずのDHCPからなぜかIPアドレスが取れなかったり、（手動でIPアドレス等を設定したのち）パッケージリポジトリへの接続段で通信ができなかったり、と何やら通信がおかしい。

PCとスイッチの間のケーブルは直前まで通信ができていた別のマシンのケーブルを差し替えてつかっており、さらにスイッチのリンクアップのLEDはちゃんと点灯していてなぞ。

一通りインストールが終わった後で改めてマシンのログインして確認するとどうやらNICのドライバがロード出来ずにエラーが出てる・・・。

なぜ、昔のDebianで通信出来ていたのに、最新のDebianで通信できなくなるのか・・・、簡単には解決できなかったので継続調査で。

VMware Workstation 15 Player の仮想マシンに何かをインストールしたシリーズ第2段で、今回はLinux Mint LMDE(Linux Mint Debian Edition)3をインストール。

選択理由はLinux のデスクトップを触りたくなったので。

インストールは画面解像度がインストール中の画面解像度が微妙に小さいサイズで固定されていて、選択メニューの項目を決めたあとに確定させて次に進む際のボタンのほとんどが画面範囲外に出ていて押しづらい事以外は問題もなく詰まることなく進行して完了。CentOSの時のように最初の再起動後にNICがONBOOT=noになっていることもなく、apt update/upgradeも大きな問題なく完了。

さて、触ってみようか。

やけに長いタイトルになりましたｗ

タイトルの通りで、CentOS8がリリースされて半月以上経過したし、そろそろ8を軽く触ってみようということで、比較の為のCentOS7とCentOS8のインスタンスを用意することにしたんですよ。

自宅のサーバ系マシンはRaspberry Piがほとんどになっていて、改めてCentOSを入れられる空いているPCがないという事で、ほんの少し思案したのち「VMware PlayerかVirtualBoxかをインストールして、その上にインスタンスを用意すれば良いじゃん！」という結論に。ここしばらくVMwareの方を触っていないということで、VirtualBoxではなくVMware Workstation 15 Playerをダウンロードして来てインストール。

最後にVMware Playerを触ったのはいつだったかな～？と思いながらCentOS7とCentOS8のISOイメージを用意して仮想マシンをセットアップ。
そう言えば、仕事の方でCentOSを触るときはだいたいAWSとかのクラウド環境なので、イメージからのインストールは久し振り。昔に比べるとずいぶんと導入手順とか減った気がします。

で、一通り両方ともイメージからのインストールが完了して、リブート後にrootでログインして、最初の yum update (dnf update)を実行するとエラーで止まってしまう。エラー内容を見ると「リポジトリキャッシュの読み取りができない（超意訳）」ですと。

先に試みたCentOS7の方の特有の何かかもしれない、と言う事でCentOS8の方でも試したけど、出力メッセージの細かい部分は違うけど大筋で同様のエラーで止まる。どうやらCentOS7とか8とかの問題じゃなくて、VMwareの方で何か見落としがあるんじゃないか？と思い、せっせとそっちの方の設定とかを注意して確認してみる。

しかし、仮想マシンのネットワークインターフェイスのモードはNATになっているし、変に込み入った設定をしている訳でもない。さらに、ホストPCのセキュリティ設定も特にブロックしていないし「なんでだ～？」状態。エラーメッセージをGoogle先生に確認してもらったけど、症状がぴったり一致するような解決策候補は(少なくとも1ページ目には)特に出てこない。困った！

こういうよく分からない時、そして過去にVMwareを触ったときの経験から改めて用意した仮想マシンの設定を確認することにする。「仮想マシンのコンソールはコピペとか出来ないから、設定を調べたり書き換えたりするのも面倒なんだよなぁ～」と思いながらrootでログインして設定を確認してみる。そう言えば、先にGoogle先生で調べた時にちょっと違う症状の例（IPv6設定が悪さをしているので完全にIPv6を無効にする）があったので、ひとまずIPアドレスを確認してみました。すると、なにやらビンゴに近いヒントが表示されていて、なんとNICにIPアドレスが設定されていないのを確認。え？インストーラーは変に設定変えずに実行したのに？？デバイス名とMACアドレスの情報は出てくるけど、IPアドレス周りの設定はナッシング。

おや、おや、おや、おや～？と言う事で、まずはNICの設定が書き込まれたファイルを確認してみると、なんとそのファイルの記述に ONBOOT=no という1行を見つけてしまいました。そりゃ lo しか有効になっていないのなら、yum updateは実行できないよね・・・。

取り急ぎ、ONBOOTの設定をyesに書き換えてネットワークをリスタートしてみる。あ、この時はONBOOTの効果を確認したいこともあってリスタートではなくリブートでした。仮想マシンが再起動して立ち上がってきたところで、改めてログインしてyum updateを実行すると、予想通りにさっくりと処理が始まりパッケージの更新処理に。

わーい！直った！

と言うわけで、この記事の要約としては、VMware Workstation 15 Player の仮想マシンに CentOS をインストールした直後、yum updateが不可解なメッセージが出てきたらNICの設定がONBOOT=noになっていないか確認しよう！でした。