新しいPCを組んだときのメモ

新しいPCについて⌗

今回関東に引っ越しするのをきっかけに新しいPCを組んだ。正直既存のPCでそこまで性能には困ってなかったし、前に組んでからまだ3年くらいしか経ってないので早すぎた感もある。とはいえ、増え続けるメディア系にストレージは追いつかないし、軽く編集しようにも動画編集するにはスペックが少し不足気味ということで全く需要がないわけではなかった。古いPCパーツはほとんどは後輩にあげてしまったが、正直残しておいてサーバーにすればよかったかもしれない。

今回の構成⌗

今回はかなり奮発して構成している。旧PCから使いまわしたのは電源とケースと一部HDD、SSDのみ。

種類	製品・仕様など
マザボ	ProArt X670E-CREATOR WIFI
メモリ	16GB x 2
CPU	Ryzen 7700
SSD	1TB M.2 SSD x 2
GPU	RTX 4070Ti

だいたいこんな感じ。マザボが8万、GPUが13万、CPUが5万くらいなのでこれだけで20万オーバー、その他色々入れたらパーツだけで30万。これに加えて映りがよいモニターはほしくて LGの4Kモニター(27UQ850-W)も買ったので、なんだかんだ40万くらいはした感じ。

さらに、最近のマザーボードはけしからんことにSATAが少ない傾向にあり、多くても6本で6本ついてるマザーボードはかなりレア。基本的には4本が主流で少ないものなら2本というものもある。前にPCを組んだときは8本とかついてる製品も別に高くないものでも普通にあったし、前のマザボはそれくらいあったきがする。

SATA接続のストレージはメインにはならないが、動画や写真その他ドキュメント類など色々保管しておく倉庫にするし、重要な思い出データなども多数あるため多少冗長性を考慮してRAIDを組んだりするのでSATAが少ないと困る。ということで、Linuxでも動作すると噂の玄人志向のSATA拡張ボードも購入している。

OSの構成⌗

OSはこれまでと同様にWindows/Linuxのデュアルブートで構成している。前回はWindows側はケチってSATAのSSDにインストールしていたが、今回はM.2 SSDを2枚さしてそれぞれにWindowsとLinuxをインストールする構成としている。

Linux動作について⌗

新しい構成だと心配になるのがLinuxがちゃんと動作するかということだが、結果から言えば正しく動作している。ただし、マザーボードのRAID機能(fakeRAID)はドライバがないので認識しない。後述するがfakeRAIDのせいで面倒なトラブルにも巻き込まれたので、Linuxを使う予定の人はこれは使わないほうがいい。というか正直今回のトラブルを鑑みると、fakeRAIDなんて機能は今後仮に使える環境だったとしても使わないかもしれない。

トラブル1⌗

今回発生した大きなトラブルとして、fakeRAIDを一度有効にしたあと無効にした結果マザボのUEFI設定画面に入れなくなるというものが起こった。結論から言えば、最終的にはBIOSのアップデートにより解決することができた。

もともとマザボのRAIDでRAIDアレイを1本作り、それをNTFSでフォーマットすることで暗号化はできないが Windows/Linux共有の大容量ストレージとして利用することを構想していたのだが、前述の通りマザボのRAIDはドライバがなければ読み込めないことを失念しており、Linuxでは案の定ドライバがなかったため読み込めず断念した。（認識すらしない）

以上の経緯で、一度SATAのRAID機能をONにしたがあとからOFF(AHCI)にするという操作を行った。この操作をした結果、ブート中にF2やF8を押してUEFI設定（BISO設定）やブートメニューを開こうとすると画面が暗転したまま何も表示されなくなるという現象が発生した。この現象に対して下記の解決策は無意味であった。また、この現象が発生していてもOSは通常通り起動でき、 LinuxのブートローダーでWindowsを呼び出せるようにすることでマザボのブートメニューが開けなくても両OSを起動できた。（ただし、この状態では何らかのマザボの設定変更は不可能であり、万一Linuxが破損してUSBなどからブートして修正しようとした場合、 USBのブートも選択できないことから解決する必要があった）

• 電源を一度完全にOFFにする（コンセントも抜く）
• RAID化していたドライブを接続解除またはRAID化していたドライブの中身のフォーマット
• マザーボードのCMOSクリア
• Windows上からマザーボードの診断を実施

正確な原因は現在も不明ではあるが関連するパーツとして玄人志向のSATA拡張ボード（SATA3-I6-PCIE）が関連していることが判明した。このポートをマザーボードから抜くことでマザボの設定画面は表示されるようになった（さし直すと再度表示されなくなる）。またその後の調査によって、SATA拡張ボードにSATAドライブが2本以上接続された際に設定画面が表示されなくなることがわかった。つまりSATAドライブが１つも接続されてなければボード自体を接続していても問題なく設定画面が表示された。ちなみにこのSATAドライブは最初にRAID化したドライブではない。また、SATAドライブを外してBIOS設定画面を開きSATAの設定をRAIDに戻したところ SATA拡張ボードおよびSATAドライブを複数さした状態でもBIOS画面は表示された。（設定変更が必要なときなどだけSATA拡張ボードを抜くという暫定運用も可能ではあったがダサいので解決を続行した。また、SATAをRAIDモードにして利用するというのもマザボ側のSATAポートはLinuxでは使えなくなるが拡張ボード側の6ポートは使えるため当面問題はない状態だったがこれもなんだかもやっとするので実施しないこととした）。

関連するパーツはわかったものの、パーツを抜く以外に解決策がない状態であったため、最終的にはマザボのBIOSアップデートを実施した。（SATAは一部のシステムファイルに活用しているものの、基本的にはOSの起動には関連しないストレージであったため、USBブートやマザボの設定変更などが必要になった際にだけ拡張パーツを抜くという運用も不可能ではなかったが、ダサいと思ったのでなんとか解決を続行した）

今回購入時点のバージョンは05XXというおそらく最初のバージョン。今回は当時最新だった17XXというバージョンに更新した。ちなみにUSBに相性があったのか2本のうち1本のUSBではアップデートができなかった。とはいえ無事にアップデートでき、起動した結果SATA拡張ボードおよびSATAドライブを複数指した状態でもBIOS設定画面が表示できるようになった。

ただし、試していないので実際どうなるかはわからないが再度SATA設定をRAIDにした場合同じ現象が再発する可能性があるため完全に解決したかは不明である。一旦今後の運用に問題はなくなったので今回はここで問題は解決できたものとする。

マザボのfakeRAIDはチップメーカーに依存しているし、ハードウェアRAIDのように見えてソフトウェアRAIDだし、OS上で死活監視やメンテナンスなども実施しにくいし、今回のような謎トラブルも起こりやすいということがわかったので今後はよほどのことがない限りは利用しない方針としたい。（一時的にONにすることすらしない）

トラブル2⌗

上記のトラブルに起因してもう１つトラブルが発生した。上記のBIOSアップデートによりUEFIの設定が消えてしまい、再度ArchLinuxなどは調整が必要な状態となったが、今度はLinuxが起動できないという問題が発生した。Windowsの起動は問題ない。

ArchLinux isoを書き込んだUSBから起動すると下記のような画面でハングする。

“nouveau 0000:01:00.0: unknown chipset (194000a1)“というメッセージを最後に停止しており、nouveauといえばオープンソースのNVIDIAドライバなのでグラボ関連かと思ったが、“debug"をカーネルオプションにつけてブートすると次のようになった。

先程のエラーで止まっていたわけではなく、更にその先まで進んでいる。実際に止まっていたのは”[drm] JPEG decode is enabled in VM mode"である。

こちらの問題は割と解決に時間がかかってしまったが、こちらについては原因と解決策は理解できた。結論から言えば、今回のBIOSアップデートに起因して外部のGPU(NVIDIA)とCPU内蔵のGPU(AMDGPU)が両方OSに認識される状態となったが、 AMDGPUのほうの初期化（drmの初期化）に失敗しており、その時点でハングしていたというのが原因。解決策としては、起動時にオプションをつけてdrmのAMDGPU読み込みを無効化する。今回のグラボは外付けのRTXであるためOSの動作としては全く問題はない。具体的なブートオプションとしては、“modprobe.backlist=amdgpu"を起動時のカーネルパラメータに設定することで本問題を回避して起動できるようになる。

USBブートの場合は起動したブートローダーのブートメニューから一時的にパラメータを変更できるし、インストールしたOSに対しては利用しているブートローダの設定を書き換えることで実現できる。例えば、Limineの場合は次のようにすれば良い。

:Arch Linux
    PROTOCOL=linux
    KERNEL_PATH=boot:///vmlinuz-linux
    CMDLINE=root=UUID=XYZ resume=UUID=XYZZY rw modprobe.blacklist=amdgpu
    MODULE_PATH=boot:///initramfs-linux.img

今回の問題については、すぐに解決ができなかったのでしばらくはWindowsを利用していた。Windowsのタスクマネージャーを眺めているとGPUとしてGPU0とGPU1が認識されており NVIDIAとAMDGPU両方がOSから見える状態となっていることに気づいた。これは購入当時とは異なっており、初期のBIOSではNVIDIAのみが認識されていた。マザボのサポートに確認するとどうやら過去のアップデートで両方のGPUを有効化する更新が入ったらしい。（この修正内容が最初に入ったBIOS06XXXは現在公開停止されておりWeb上から変更内容は確認できなかった）。

最初の画面からなんとなくGPU周りっぽいということはわかっていたので、ここから更に調査を進め、Linuxのdrmのコードなどから最後に表示されているメッセージ"JPEG Decode … “などを探していくとどうやらamdgpuの初期化に関するプロセスであることが理解できた。ということで、amdgpuならOFFにしても全く問題ないのでブート時にこれを読み込まない方法を調べて、実際に上の通り試したところ無事解決できた。

最初はNVIDIAの問題かとも思ったので、仮想マシンで最初からNVIDIA商用ドライバが入っており、OSSのドライバは無効化されたarchisoを作成しそれで起動なども試してみたが解決できていなかった。（archisoは初めて作ったが案外かんたんに作れて驚いた。ただし、NVIDIA商用ドライバをarchisoに入れる場合mkinitcpioなどで一時的にかなりメモリが必要となる。これは/tmpに書き込みが必要だが /tmpは基本RAMの半分程度の容量となるためである。このあたりも設定方法があるかもしれないが、今回は32GBものRAMを積んでいるので仮想マシンに16GBのメモリを割り当ててゴリ押しで解決した。）

ということでかなり手間はかかったものの現状ではWindows/Linuxともに問題なく稼働できる状態となっている。

最後に⌗

Linuxについては上に加えて念の為NVIDIAのOSSドライバではなく、商用ドライバをinitramfsに含めるように設定しており起動後可能な限り早く読み込めるようにしている。この方法についてはArchWikiに詳しい手法が書いている。基本的にはmkinitcpioでinitramfsに含めることができる。

かなり手間はかかってしまったもののなんとか実用できる状態になってよかった。今まではLinuxはPlasmaを利用していたが、Plasmaは更新頻度が多く、やや重たいこともあって今は試しにxfceを利用するようにしてみている。悪くはないが、さすがにPlasmaと比べると機能面では見劣りしている気がする。安定性も正直どっちもどっちだ。あとはLinuxはモニター解像度の調整が下手くそで、うちではFHDと4Kモニターを混在させているものの、この状態ではFHDに合わせると4Kモニターは字が小さくなりすぎるし、 4Kモニターに合わせるとFHDはクソデカ表示になってしまう。かといって4Kモニターの解像度を落として使いたくはない（モニターからも非推奨という警告が出るし）。まあ、ここは良い塩梅に調整して多少は目をつぶるしかない。その点Windowsはなにもしなくてもよしなにやってくれるのでさすがである。

Windowsのデスクトップの安定性、多様な商用ソフトウェア（互換性）とLinuxの自由度の高さを兼ね備えたUNIX系OSがあれば天下無敵だと思うのだが世の中なんにおいてもそんな都合のよいものはない。思い起こせば、AとBがあったときAとB両方の利点を満たせるものがあればいいのにと思うことは非人工物（材料や物質、物理現象など）においてはよくあると思うが、人が生み出したシステムやソフトウェアにおいてもこんなふうになってしまうのはなんとも無慈悲な感じがする。

まあ、長くなったが備忘録という意味も込めてここに残しておく。しかしやはり漫然とデスクトップOSとしてLinuxを使っていても得られるものは何もなく、このようなトラブル解決などを行ってこそ、それをきっかけで知識が増えたりするので良いと思う。とはいえ、通常利用を脅かすようなトラブルは遠慮したいところである。