ペガソス計画(19) - 週刊「ファランクスを作る」

　と、いうことで、3年半前に購入して以来、永らく放置してあった「Jetson TX2 Development Kit」を、最新の状態にすることにします。

　画面は、ホストPCとなる自作水冷マシンで、「Ubuntu」（18.04.6 LTS）を立ち上げたところです。

　Jetsonのクリーンインストールと言えば、約8年前に「Jetson TK1」を購入し、当時はほとんど情報がなかったため、かなり苦労して最新化した記憶があるため、これまで避けていました。

＃面倒くさいことは、避けてばっかり。0xF9C7

　Jetson TX2を、リカバリモードで立ち上げ、ケーブルを接続すると、ホストPCからは、USBデバイスとして認識させることができます。

　ホストPCに、「nVIDIA SDK Manager」（1.8.1.10392）をインストールし、起動すると、「Jetson TX2」が認識されました。

　ここから、Jetson TX2に、最新のJetPack（現時点では4.6.2）をインストールします。

　無事に、Jetson TX2上で、Ubuntu（18.04 LTS）が起動できました。

　と、簡単に書いてますが、ここまで来るのに、盆休みの2日間を要しました。0xF9C8

　まず、ホストPCに、仮想環境を作り、そこでUbuntuを起動し、SDK Managerを動作させようとしました。

　具体的には、ホストPCに「VMware Workstation Player」（16）をインストールし、その上で、Ubuntu （18.04 LTS）を起動させました。

　しかし、何度やっても、インストールの途中で前に進まなくなってしまいます。

　いろいろ調べてみると、どうやら、仮想環境上のUbuntuでは、SDK Managerが上手く動かない“らしい”。

　仕方がないので、“仮想”ではなく、“物理”でUbuntuを起動させるべく、ホストPCにインストールすることにしたのですが・・・。

　同一ディスク上に、Windows10とUbuntuをインストールする「デュアルブート構成」では、Windows10側に不具合が出る可能性が高いとのことで、ディスクを分けることにしました。

　使い古しの（容量の少ない）HDDやSSDなら、たくさん転がっているので、一時的に接続すればことは済むのですが、またも別の問題が。

　Ubuntuのインストーラーの不具合で、インストール対象となるディスク以外のディスクが繋がっていると、間違ってそちらに書き込んでしまう可能性があるとのこと。

　最新鋭の自作水冷マシンでは、マザーボード上にM.2 SSDが取り付けられ、さらに、その上に、水冷ブロックを組み込んだグラフィックボードが組み込まれていることから、容易にM.2 SSDを取り外すことができません。

　仕方がないので、前世代の自作水冷マシンに、SSDを取り付け、Ubuntuをインストールしようと起動してみたところ・・・。

　1ヶ月近く放置プレイされていたことに気を悪くしたのか、はたまた、新しいカノジョに付きっきりなことに気を悪くしたのか、ちゃんと起動してくれません。

＃クルマでもよくありますよね。最新モデルに浮気しようとすると、途端に調子が悪くなるとか。0xF9C7

　なんだかんだで、前世代の自作水冷マシンにUbuntuをインストールし、起動できるようになるまで、一昼夜。

　いよいよ、“物理”環境上でSDK Managerを動作させ、インストールを始めたのですが・・・。

　やっぱり、同じところで、前に進まなくなってしまいます。

＃どないなっとんじゃい！0xF9C9

　SDK Managerでのインストールでは、ホストPCとJetson TX2を、USBケーブルで接続し、必要なファイルをJetson TX2にフラッシュします。

　この時、ホストPCとJetson TX2とは、仮想的にLAN環境で接続されたことになっており、その際のJetson TX2側のIPアドレスは、「192.168.55.1」になっています。

　そこで、この“仮想的なLAN接続”が、上手くいっていないものと想定し、接続方法を変えてみることにしました。

　SDK Managerのインストール手順の前半に、「Automatic Setup」と「Manual Setup」とを、選択できるところがあります。

　これを「Manual Setup」とし、LANケーブルを使って“物理的に接続”し、IPアドレスを、以前にJetson TX2で遊んでいた時の「192.168.11.xx」にしてみたところ、インストールが前に進みました。

　ハッと思って、仮想環境上のUbuntuでSDK Managerを起動し、SDK Managerを動作させ、「Manual Setup」を選んだところ・・・。

　同じように、インストールが前に進みました。0xF9CF

　ということは、ホストPC側のUbuntuが、仮想環境か物理環境かは関係なく、単に「Automatic Setup」を使わず、「Manual Setup」を使ってIPアドレスを手動で設定すれば、正しくインストールできることが分かりました。

　ちなみに、以前のJetson TX2側のIPアドレス（192.168.11.xx）は、インストールが途中で中断し、Jetson TX2の内蔵メモリがフラッシュされなかったことから、たまたま残っていたもので、「Manual Setup」を使えば、仮想的なLAN接続（デフォルトの「192.168.55.1」）のままで、正しくインストールされます。

　ここまで来るのに、1日半。0xF9C8

　Jetson TX2に、JetPack 4.6.2がインストールされ、Ubuntu 18.04 LTSが正しく起動したことが確認できたところで、もろもろの設定をすることにしました。

　まず、Jetson TX2内蔵のeMMCが、32GBと少なめのため、外部にSSD（240GB）を接続し、関連のファイルを移動しました。

　さらに、eMMC上に確保されているスワップ領域が、16GBとなっているため、外部のSSDに、新たにスワップ領域を確保しました。

　なお、せっかくなので、外部のSSDからシステムを起動させることを考えましたが、Jetson Nanoではなく、Jetson TX2では、外部SSDからのシステム起動は相当に難しいようなので、現時点では見送りました。

　ちなみに、「hdparm」でディスクのアクセス速度を確認したところ、内蔵eMMC（/dev/mmcblkp1）が「230.08MB/sec」、外部SSD（/dev/sda1）が「267.20MB/sec」と、期待したほどの違いはありませんでした。

　よって、無理して（膨大な時間を掛けて）外部SSDに移し換えずとも、起動時間にそれほど違いはないだろうと判断しました。

　ちなみに^2、Jetson NanoにおけるSDカード（/dev/mmcblk0）のアクセス速度は、「85.49MB/sec」とかだそうで、これだけ遅いなら、外部SSDに移し換えるメリットはありそうです。
（Jetson Nanoなら、起動時間が1/3（単純計算で）になるかも？）

　ポイントとしては、SDK Manageが終了してからSSDをmountするのではなく、SDK Manageの途中で、Jetson TX2がいったん起動した際に、手早くSSDをmountし、関連のファイルをSSDに移動することです。

　なぜならば、SDK Manageの後半は、CUDA関連やなんやらの、もろもろのファイルをeMMCに書き込むため、無駄にeMMCの容量を消費してしまうためです。

　何度かクリーンインストールを繰り返して分かったことですが、SDK Manageが終了した段階でSSDに移動すると、eMMCは約12.82GBが使われていましたが、SDK Manageの途中の段階でSSDに移動すると、eMMCは約5.45GBが使われていました。
（差分は、SSDに書き出されているということ）

　と、いうことで・・・、

　盆休みの2日間を消費。

＃まぁ、大宗の田舎モンとは違うので、わざわざ大渋滞や大混雑の真っ只中に突っ込んでいって、無駄に時間を消費するよりはマシですわな。0xF9D1

　紆余曲折ありましたが、いちおう、永いこと放ったらかしにしてあったJetson TX2を、ひょんなトリガで、最新の状態にすることができました。

　CUDAのサンプルプログラムをmakeし、動かしてみましたが、smokeParticlesで40.0fpsを、コンスタントにマークしてくれます。

　めでたし、めでたし。0xF9CF

（つづく）