EFI+GRUBで悩む

久しぶりにEFI+GRUB関係で悩みました.

今,メインサーバーはSlackware ARMで動いてます.Raspberry Pi に切り替える前まで,メインサーバーだった,Core i7のデスクトップ機は,無任所workstation (WS)として存在していますが,とにかく使用目的がないので動かすのがまれで,そこそこのマシンパワーを持っているのに,持ち腐れ状態です.

最近,無線関係の機器を作りたい気持ちが高まってきていますが,まずは,GNU Radioでソフト的に遊んでみることにしました.Mac miniとMacBookには,Mac PortsでGNU Radioがインストールできましたが,そもそも非力だし,動作に怪しいところがあるので,そこで,このWSを使おうと思いつきました.

このWSはサーバー時代のままSlackware64が入っています.以前はSlackwareで,GNU Radioを手でbuildしたものですが,今はどうもそんな気力がありません.となると,UbuntuとかDebianです.Ubuntuはどうにもあかん(当社調べによる)ので,それならDebianにすることにしました.

Debianは既にそのWSの仮想マシンとしてインストールしてありますが,実時間性が必要となる信号処理で仮想マシンはたいていうまく動いてくれません.そこで,比較的余裕のあるルートディスクにパーティションを切って,Debianをクリーンインストールしてdual bootにしてしまおう,というところまでが,まえがきです.

EFI+GRUBはかつて,かなり苦労してそのWSに導入しました.GRUBは良く出来すぎていて,一度イントールしたら,kernelをupdateしても,ちょこっとしたおまじないでconfigファイルを書き直すだけでいいので,ほとんどいじることがないので,もともとよく理解しないままインストールした上に,すっかり忘れてしまいました.

そんなわけで,ただ元のルートディスクの中身を他のディスクに書き出して,その他の方からブートして,元のルートディスクに書き戻す,というだけの作業で苦労してしまいました.コピー自体は,rsyncを使う自作スクリプトで簡単なんですが,コピー先からのブートで難儀しました.

いろんな罠にハマりましたが,特に残念なのがGoogle検索です.GRUBのコマンドラインについて調べると,GRUB1についての解説が上位に出てきます.GRUB1と2ではコマンドの基本的な文法に大きな違いがあって,参考になるどころか害悪をもたらされ,時間を空費しました.

それでもなんとか,EFI+GRUBで,もとのSlackware64にてブートできるようになりました.最終的な手がかりは,自分の非公開Wikiに書いてあるメモでした😓 少しわかりにくい部分があったので,いつあるか解らない次回のために加筆修正しておきました.

このあと,あけたパーティションにDebian AMD64版をインストールして,GNU Radioもインストールしてみます.

時計が合わない

macOSをCatalinaにアップグレード(UG)して,使えなくなったVMWareをUGして,結局,WSJT-Xは,macOSのネイティブアプリもWindows版をVMWare上でも使えないと確認できて,死蔵していたWindowsの実マシンでWSJT-Xを使うようになった話の続きです.

どうも,時計が合いません.起動直後や,運用の合間にも時々,手動でタイムサーバーへの同期ボタンを押すのですが,受信局の時間遅れが1秒台ということが多いです.

受信する局の多数が1秒以上遅れているということは,こちらが1秒以上進んでいると考えるのが妥当でしょう.

タイムサーバーを変えてみても状況は変わりません.

macOSのネイティブのWSJT-Xでは,受信する局のほとんどが0秒台前半なので,こちらもあっていると確認できます.

Linuxだとntp(d)が普通についていて,同期すべきタイムサーバーを設定すれば,いちいち手動で同期ボタンを押さなくてもPCの内部時計が常に正確な状態が保たれます.

macOSは詳しいことは解りませんが,Linuxの多くのdistroと同様の仕組みと思います.

Windowsの仕様なのかAMD A6を搭載したこのポンコツPCのチップセットがタコなのか解りませんが,どうにもしようがない状況なので,「あいつの信号はいつも1秒以上ずれている」と責めないようにお願いいたします😥

追記: 時計合ってます

2019年11月9日にMac miniをMojaveに戻し,以後はWSJT-XのmacOS版に戻りましたので,時計は正確です.

2019年11月15日

ntpを使っていないLinux distroの存在を知りませんでしたが,Chronyとopenntpdというのがあるようです.

Catalina UGの後始末

結局,WSJT-Xのみは,Windowsの実機(AMD A6 Windows 10 32bit)で,動かすことにしました.その他のアマチュア無線関係のソフト, N1MM+, MMTTY, Log200は,引き続き,Mac miniのVMWare Fusion 11.5下で,Windows 8.1の仮想マシンを走らせて,そこで動かします.

VMWare Fusion上のWindows 8.1仮想マシンと,USBリソース(CAT用のUSB-serialアダプターと音声信号入出力用USB-audio)は,KVM Switchで切り替えると不具合が生じましたが,これを避けるために,基本的に両方のWindows環境を起動しないこととします.また,KVM SwitchでMacとWindows実機をどうしても切り替える時は,USBの切り替えを伴わない,HOT Key 2回, ポート番号, k, リターンという手順で切り替えることにします.

Windows実機では,S/Nが-20dBを下回る信号もちゃんとデコードしてくれます.macOS版のWSJT-Xと同等のデコード性能と思います.

たぶん,VMWare Fusion下では,単純な時間遅れが生じているのかもしれませんが,それより問題になるのは,スケジューラーによるタスクの切り替えで,仮想マシンの時間軸にjitterが発生して非線形(時間のjitterは,相対的に入力信号のjitterになります)となっていることでしょう.このため信号のデコード(信号を重ね合わせてランダムノイズを除去する)で大きな不利になっているのでしょう.あくまで推測で,確認・検証などはしません^^;

傍証として,VMWare Fusionで動かしているWindows 8.1 (32bit)上で,DFUSe Demoを使って,nanoVNAにファームウェア(固件)を書き込むのがうまく行かない(書き込みの途中で必ずエラーになる)というのがあります.

Catalinaにしました

Catalinaにするか迷ったその日からほどなく(たぶん翌日^^; ),メインのWSもCatalinaにupgrade (UG)しました.これまでオレ様流でいくつかのデータをルートに置いていましたが,CatalinaにUGすると,そうしたファイルが,ホームディレクトリー下の訳の分からないディレクトリーに移されることも知っていたので,修正してからUGしたので,行方不明になるファイルもなく,VMWare Fusion 10.5も起動しました.

しかし,known problemで,VMWare Fusionは11.5にUGしないと,画面が表示されません.ただで済ます方法もあちこちにありますが,有料UGしました.

他にもかなりのmacOS用アプリが,今回のmacOS CatalinaへのUGで,使えなくなりました.たいていはまあなくても済むものですが,一番困ったのは,WSJT-Xです.これがCatalinaで動かないのもknown problemのようです.何年も前から,近い将来のmacOSでは,動かなくなることが解っているのに,なぜ開発チームは古いtool chainに固執したのかという批判もネットで散見しますが,まあ,他力本願なので,私は文句は言いません^^;

そこで,せっかく有料UGしたVMWare Fusion 11.5でWindows版を動かしてみました.最初,設定の問題で,全くデコードされず,ずいぶん時間を無駄にしてしまいましたが,なんとか,送受信できるようになりました.

しかし,Mac版WSJT-X 2.1.0をmacOS Mojaveで動かすのに比べて,どうにもデコードの能力が劣ります.強い信号がいくつも入っているのに,一つもデコードできないこともありますし,デコードできるときも,S/Nの下限がmacOS版に比べてかなり悪い(強い信号でないとデコードできない)です.

VMWare Fusionには,昔からオーディオのlatencyの問題があるようです.VMWare Fusionの度々のUGで改善されてきてはいるのですが,まだWSJT-Xの能力を完全に発揮するには不十分のようです.

あるいは,2core 4taskのCore i5で動かしていて,VMWare Fusion下のWindows 8.1には,2taskを割り与えていますが,マシンパワーが足りないのかも知れません

そんなこんなで,一応予備に持っている,Windowsの実機を試してみました.通常の運用(主にN1MM+, MMTTY, CW Skimmer/Skimmer Server, Log200を使用)では,引き続き,VMWare Fusionを使用したいので,兼用するオーディオ入出力IFとメインリグのCATは運用の度に差し替えなければならないです.これは,誤操作や故障の元です(コネクターを日に何回も抜き差しして,寿命になったことはけっこうあります).

次に考えついたのは,私はMacintoshと,Raspberry Pi 4 Model Bと,core i7のLinux WSと,そのWindowsの実機をKVM Switchで切り替えて使ってるのでした.このKVM Swichには,USB 2.0ながら,USBの切り替え機能も付いているので,CATのUSB-serialコンバーターとUSB-audioアダプターもこのKVM Switchにつなげば,スマートに切り替えて運用できるではないかな,ということです.

さっそく手持ちのUSB 3.0 HUBをKVM Switchの下につないでみましたが,認識してくれません.そもそもUSB HUBってものすごく相性の問題がありますが,親が2.0で子が3.0では困難さが増大するようです.

ということで,USB2.0 HUBを注文しました.届いたはいいんですが,手持ちのUSB2.0 HUBが一つ見つかりました^^; まあ,予備として取っておきます.

KVM Switch下にUSB2.0 HUBをつなぎ,その下にFTDX5000MPのCATにつながるUSB-serial変換器と,デジタルモードのオーディオ入出力に使用しているUSB-audioアダプターをつないでさっそく試してみました.

あきません^^; MacからWindows実機に1度切り替えて戻ってくる,VMWare Fusionの側で,切り替えていないUSBポートにつながっているものも含めて,全てのUSB機器が見えなくなります(VMWare Fusion本体を再起動することで見えるようになります).これはバグに間違いないですが,どうしようもないです.

もう一あがきしてみます.

最新の2.1.0でNG.
VMWare Fusionにfamiliarではない方への注釈ですが,VMWare Fusionの仮想マシンの時計は,ntpで同期しているMacintoshの時計そのままを使っているので時計が狂っていることはありません.
2taskを割り与えても,ホストの管理下で動くので,ゲストOSはフルに2task分のパワーを使えるわけではないです.

miniVNA

前稿で,miniVNAについて触れましたが,当サイトのBLOGをWordPressに移行してから,一度も紹介したことがなかったことが,後で解りましたので,簡単に説明します.

miniVNAでネット検索すれば概要は解ると思いますが,私が持っているのは,miniVNA Pro BTという,Bluetoothにより,PCと接続できるタイプのものです.いつ買ったのか忘却の彼方ですが,小遣い帳^^; によれば,2012年に,4万円弱で個人輸入しています.

miniVNA

本体にディスプレーや操作ボタンがなく,必ずPCと接続して使います.Bluetoothもしくは,USBケーブルで接続して,Macintoshはもちろん,LinuxやWindowsでも使用できます.また,ちょっと使い勝手は違いますがAndroid用のappもあります.

PCで使いますから,周波数のプリセットや,測定データの保存などは楽々できます.

ただ,日頃使っていれば良いのですが,たまに使うと,Bluetoothでの接続や,ソフトのアップデートに伴う校正のし直しが必要で,測定しようと思い立ってから,実際の測定まではすんなりたどり着けないことが多いです^^;

その点,今回購入したnanoVNAは,スタンドアロンで,フィールドでの使用には断然便利と思います.スイッチを入れて2秒ほどで測定可能になります.本格的なVNAはたいていWindowsで動いているので,電源を入れてから測定ができるようになるまで何分も待たされると思います.

もう一つのminiVNAの欠点は,測定周波数が200MHzまでということです.430MHzのアンテナの調整には使えません.後のモデルは,1.2GHz帯も測定できるようになったのではないかと記憶していますが,430MHzや1.2GHzのアンテナを自作するわけでもないので,買い換えは全く考えませんでした.

その点,nanoVNAは900MHzまで測定可能で,430MHz帯のアンテナの調整にも使えます.とはいえ,市販のアンテナでは特に調整することもないので,ちゃんとつながっている,故障していない,等の確認にとどまりますが^^;