システムクラッシュしたパッケージ版PiAwareを6.1へ手動ビルドインストール

PiAwareパッケージ手動ビルド (1) tcl-tlsパッケージ

fsck を終えて作業を再開しますが、バッチスクリプトの中身を読み、少しずつ手作業で確実に進める手法へ路線変更します。先ずはビルドに必要なツール類のインストールを --reinstall オプション付で強制再インストールさせます。

続いて、tcl-tlsパッケージのビルドに必要な依存パッケージ類を同様に強制再インストール。

そして適当な作業フォルダを作成し、その中でPiAware向けのtcl-tlsパッケージを git clone でソース取得の上、パッケージビルドします。

途中の通信試験で失敗が検出される問題は、OpenSSLのTLSセキュリティレベルを少し下げることで通ってくれるのだそうです。

再トライでは通信試験は通過しましたが、その先でまたエラーです。

Segmentation faultを吐いていたのは xargs であったので、これを含むfindutilsパッケージを再インストールすると、エラーは解消しました。

こうしてパッケージビルドはようやく完走したので、出来上がったdebファイルをインストールします。

 

PiAwareパッケージ手動ビルド (2) piawareパッケージ

ここでもまずは、必要な依存パッケージの再インストールから。

作業フォルダのトップへ戻り、piaware_builderパッケージを git clone でソース取得の上、パッケージビルドします。

指摘されたboost系のファイルに文字化け破損が複数目視されたので、まだ再インストールしていないboost系パッケージがないか探し、 libboost1.67-dev を上書き再インストールすることで、当該ファイルの文字化けは解消しました。。

とにかくこのパッケージビルドは重い処理なので、ハングしてしまったらデバイスを強制再起動して再実行するしかありません。それももう少しで完走ということろでまたもや文字化けエラー検知です。

これは、libtcl8.6の上書き再インストールで解決しました。

これで長い長いパッケージビルドが完走したので、出来上がったdebファイルをインストールします。

 

dump1090-faパッケージ手動ビルド

続いてもう1つ、FlightAware版のdump1090パッケージも同様に、バッチスクリプトを手動でなぞりながらパッケージビルドの上、インストールします。ビルド関連ツールは既に再インストール済なので、依存パッケージの再インストールから取り掛かります。

作業フォルダのトップへ戻り、dump1090パッケージを git clone でソース取得の上、パッケージビルドします。

これもかなり長い間待たされますが、warningは出力されるもののエラー無く完走しました。出来上がったdebファイルをインストールします。

 

フィーダーIDを設定して復元

こうしてPiAwareシステムは復元されました。ステータスを確認してみると、フィーダーIDが変わってしまったので、マイADB-Sページに表示されている「Unique Identifier」をコピーしてから、本来のID値を piaware-config コマンドでPiAwareへ渡します。

しばらく稼働させてから、FlightAwareのマイADS-Bページを再び確認すると、数日ぶりにオンライン状態へ復帰しました。

昨今の疫情により、ここ香港でも航空機の往来が激減しており、ご覧のようにSkyAwareによる受信状況の確認もなかなか難しい状況です。

アダプティブゲインの効能

PiAware 6の最大の変更点であるこのアダプティブゲインは、レシーバの利得をダイナミックに可変しようという機能らしいのですが、まだまだ皆さん攻めあぐねているのか、「どうすればいいのかわからない」状態と言うのが正直なところかもしれません。

デフォルトでは無効になっているので、パッケージ版PiAwareでは以下の要領で設定ファイルを編集後、サービスを再起動して反映させます。

サービスのログにも利得を頻繁に可変させている様子が確認出来ます。この状態で一週間ほど稼働させてみたろころ、観測出来た航空機数がむしろ1割ほど減っているように感じます（下図グラフの11/25〜28が本障害によるオフライン期間）。

そこで再びこの機能を無効にしてみたいと思います。

この状態で一週間ほど運用してみたしたが、一割弱受信データ量が増えた程度で、それが航空事情の変化なのか、利得によるものなのか、判断しかねる結果にとどまりました。