Category: Computer

VMWare Fusion 11.5にしてよかったかも

これまでMojaveではVMWare 10.Xを使っていて，今回Catalinaにしたら画面が表示されないと騒いでいましたが，そもそも10.xはMojaveが出る前のもので，CatalinaはもとよりMojaveでも最適化されていようはずがありません．

Catalinaにしても，無料で10.xを使い続ける手もあったんですが，結論的には有償で11.x(11.5)にアップグレードしてよかったと思っています．

やはり，Mojave/Catalinaに最適化されているようで，ゲストOSの動作がキビキビしています．10.xでは，まあなんとか使えるレベルでしたが，11.5にしてからは，十分使えるレベルになりました．

そこで，無駄に高価なSSDの数十GBものスペースを占有しているDebianのゲストOSを動かして，StretchからBusterにアップグレードしてみました．あまりDebianに通じていないこともあって，アップグレード手順を何度か（たぶん3回😥）やり直すことになりましたが，最終的にはなんとかうまくいって，今使用しています．

やり直す場合も，Debian関連文書には事前にあれこれセーブしなさいとありますが，仮想マシンの場合は作業前にSnapshotを撮って，失敗したらそこまで戻せばいいだけで簡単です．

もともと，KDEが好きなのですが，Raspberry Piのサーバーには重すぎるし，Mozcが使えないこともあって，Core i7のWSをいちいち起動しないと日本語環境のまともなKDEは使えないし，使えるとは言ってもSlackwareなので，update/upgradeの問題があります．そんなことから，KDEのためにあえてWSを起動することはほとんどありませんでした．

今後は手軽に使える仮想マシンで耐えうるスピードで動く，日本語環境のちゃんとしたKDEが使えるので，積極的に利用していきたいと思います．

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分のパワーを使えるわけではないです．

Catalinaにするか迷い中

今後のサポート・セキュリティーの観点から，いずれはCatalinaにアップグレード(以下 “UG”)すべきですが，まだちょっと迷っています．

私が現在管理者になっているMacintosh(“Mac”ときどき “マクド”)は，自分のメインワークステーション(“WS”)と，家族用のMac mini (Core i7のわが家最強Mac)，自分用のMacBook(ときどき “マクドブック”)です．

最初にWSからUGしましたが，ここで問題が発覚しました．

  1. ルートに作っていたイメージファイルなどのディレクトリーが行方不明となりVMWare Fusion(“VWF”)がそれらを発見できず，仮想マシンが動かない
  2. 上記イメージファイルなどを自分のホームディレクトリーの下に移して，VWFは仮想マシンを動かすことができるようになったが，MacBookでは，仮想マシンの画面表示が出ない（真っ黒のまま）

1は，今までのオレ様流が通用しなくなるのをあきらめることで済みますが，2の解決のためには，VWFの有料UGをしなければなりません．

それと，WSを使う上でかなり大きなウエートを占める「写真」が悪くなりました．「モーメント」がなくなり，日別の写真では勝手に写真のサムネールに大小が付けられて，いくつかの写真は表示されず「＋２」などの表示で省略されてしまいます．また，「全ての写真」で表示すると，日ごとの境目が解らなくなります．

WSでは，写真を楽しむと言うよりは管理をするので，この仕様変更は困ったものです．まだ発見はできていませんが，設定で変更できるかも知れないのでちょっと探してみます．

VWFの問題も，写真の管理の問題も，MacBookと家族用Macでは大きな問題ではないので既にCatalinaにUG済ですが，メインのWSのみ，バックアップから，Mojaveに戻して使用中です．

ネット検索すればいろいろ出てきますが，最新のVMWare Fusion 11.5をインストールして試用モードで起動して，なんやかんやして，自分のライセンスのあるVWFに戻すという手が無いわけではないですが．
表示の様式を元に戻す設定はないようですね．

FileVault

長年，公私のMacの起動用HDD, SSDは，macOS標準装備のFileVaultで暗号化してきました．

初期のFileVaultでは，暗号化をオンにすると，乱数の英数文字列が暗号化のマスターキーとして表示されて，これを使えばパスワードを忘れてもディスクが復元できる，という型式でしたが，何代か前のmacOSから，暗号化をオンにしようとすると，「復旧キーが、勤務先、所属学校、所属団体により設定されました。」という恐ろしいメッセージが表示されるようになりました．

何が恐ろしいかというと，その復旧キーを設定した組織が何かが解らないのです．最近知ったのは，/Library/Keychains/内にある，FileVaultMaster.KeychainとFileVaultMaster.cerが，その復旧（暗号化）キーの実体らしいです．そのタイムスタンプは，たしかに私はある組織に所属していましたが，本当にその組織のキーなのか確認しようがないです．Yosemiteが出る何年か前のことですし．

最初にそのメッセージが出現した頃は情報も少なく，この得体の知れない復旧キーの使用を回避するため，

  1. 起動可能な外付けHDD(SSD)に，システムをまるまるコピーする（Carbon Copy Clonerを使用）
  2. 外付けドライブから起動する
  3. 内蔵ドライブをディスクユーティリティでAPFS 暗号化の設定でフォーマットする
  4. 再びCarbon Copy Clonerで，外付けドライブから内蔵ドライブにまるまるコピー
  5. 内蔵ドライブで起動して，3の時に設定したパスワードをディスクパスワードとして入力する
  6. 管理者である自分のアカウントにログインして環境設定のFileVaultで，自分（や共同使用者）のパスワードでディスクがアンロックできるように設定する．

という手順をとりました．手順は単純明快ですが，1と4で時間がかかります．コピー中にWebの閲覧やクラウド上のファイルの編集はできますが，ローカルディスクの内容や設定を編集・変更すると，コピー先に反映されない可能性があるので，注意が要ります．

時間がかかる上，正攻法ではないので，もやもやする部分はありますが，1度設定すると，OSのupgradeでも起動ディスクは暗号化されたままなので，そのままにしてきました．

今回たまたまFileVaultMaster.Keychainの作成手順を知りましたので，得体の知れない「勤務先、所属学校、所属団体」による呪縛から逃れるために自分の復旧キーを作成して入れ替えました．

現在，この「勤務先、所属学校、所属団体」とは私自身です😀

手順はアップルサポートのサイトに書いてある通りで問題なかったです．

関係資料

ざっと調べたら，macOS 10.10 Yosemite以降らしいです．
その後，いろいろ調べて解りました．たしかに筆者がかつて所属した職場の出張所のものでした^^; 退職した組織だし，その部署は今は存在していないので，その暗号鍵が作られた経緯は解りようがなく，当然秘密鍵なども厳正に管理されていようはずはなく，一掃すべきなのは間違いないです．