技術

GA-J1900N-D3Vを買ったその後

B6-751ECcAEPeYN

B6-751RCIAA-JTw

Twitterのほうに上げたのと同じ画像ですがこんな感じになりました。

ケース: Jonsbo U2 (Silver)
電源: Corsair CX430M (ATX 430W 80PLUS BRONZE)
メモリ: CFD Elixir D3N1600Q-L4G (DDR3L SO-DIMM/PC3-12800-4GB) x 2
マザーボード: GIGABYTE GA-J1900N-D3V
ストレージ: HGSTの2.5インチHDD (320GB 移行元で使ってたものをそのまま流用)

上の写真は動作確認中に撮ったので、ストレージが昔懐かしいMicron RealSSD C400 64GBになってます。

今回、私にしては珍しくストレージ以外全部新品となってます。

まずケースですが、個人的にメーカー名の響きが微妙だなと思うんですが、モノ自体の質感は非常に良いです。
ただ、オープンベイは一切無いですし、内部ベイもちょっと無茶がある(この辺りでちょっと苦労するハメに…)し、正面から見て左側のサイドパネルしか開かないので、ちょっと癖があるっちゃあるケースです。
それ以外のパーツの配置に関しては普通なので、Mini-ITXケースにしてはまぁまぁ組みやすい方かなと思います。
まぁこんだけデカけりゃ(208(W)×319(H)×233(D)mm)当然ですけどね。

本当はこんな大きなケースじゃなくて、Antec ISK-110 VESAみたいなのがこのマザーボードには合ってると思うんですが、後から他の用途でも使えるように、例えばマザーボードを入れ替えてグラフィックカードを載せてコンパクトゲーミングPCにするとか、を考えた結果U2にしました。
いつもどおり貧乏性で割り切れない性格が出てしまったわけですね。

電源は、多分私初のCorsair & 80 PLUSなんちゃら & セミプラグイン電源です。
サーバーとして使うのでなるべく効率が良いものを…と考えつつ、信頼性もある程度あったほうがいいなぁ…と考えつつ、予算が少ないので結果CX430Mになりました。

消費電力はこの構成でアイドル19Wくらいで負荷をかけると24Wくらいです。
移行元のIntelのBay TrailなNUC DN2820FYKHが5W~10Wくらいだったのでだいぶ増えてしまってますが想定の範囲内です。

ただこのCX430MはSATA電源のコネクタが下L字になっていて、ストレージをケース底面に配置するU2とは相性が悪いというか、普通に底面設置するのは無理なんですね。
実際に組んでる最中にこの事実に気づいたとき「あぁぁ!!!」って声を思わず出してしまいました。

という事でストレージを縦にして固定するという苦肉の策でとりあえず回避したわけです。
この様子は写真にもバッチリ写っております。
ちょっと恥ずかしいです。
2.5インチHDDのネジの間隔が底面と側面で同じで助かった…
そのうち上L字アダプタでも買いたいと思います。

HDDはIntel NUCでサーバーとして使ってたUbuntu 14.10が入ったものをそのまま持ってきましたが、最初の起動でいきなりカーネルパニックw
まぁこれはすぐにBIOSの時計が2012年とかになってることに気づいて対応できました。

それから無事起動したと思ったらネットに繋がらない。
KVMを使ってる関係でNetwork Managerを止めて手動でeth0として設定してたものが効いてないようす。
ifconfig -aしたらp1p1とp4p1になってました。(このマザーボードにはNICが2つある)
この辺りも /etc/network/interfaces をちょろっと書き換えてすぐに対応できました。

で、いつものようにMacからSSHでX Forwarding接続してvirt-managerコマンドを叩くも「No D-BUS daemon running」とかエラーが出て実行できない。
でもdbusは起動してるしsudo virt-managerだと大丈夫なんですよね。
実は移行後も何度か普通にvirt-managerが使えてたのに、apt-get upgradeして再起動したタイミングで使えなくなったのか、他の作業で色々操作してたのでどのタイミングでそうなったのか謎なんですが、いつの間にかエラーが出るようになったんですよね。

でまぁ最終的にBug 890576 – Virt-manager fails to open: No D-BUS daemon runningに書いてあるように、rootで dbus-uuidgen > /var/lib/dbus/machine-id とやると解決したんですが、何故それで解決したのか正直自分の知識ではよくわかりません。
上書き前のmachine-idにはちゃんとuuidっぽいものが書いてありましたし。
ただ、machine idというくらいでマシンが変わったのでidも変えなきゃいけなかったのかなぁとふわっと思っています。
(でも、移行後もしばらくは使えてたんだよなぁ…)

あとはWindowsのVMWareで動かしてた仮想マシン(CentOS 7)のvmdkをqemu-img convertでKVM用に変換するも、dracutのemergency shellに落ちて起動しないとかあって、ライブCDで起動してdracutコマンドでinitramfsを再作成して事なきを得たりとかありましたが、この辺は今回の話に直接関係ないので省略です。

コメント

コメントを残す

メールアドレスが公開されることはありません。 が付いている欄は必須項目です



※画像をクリックして別の画像を表示

このサイトはスパムを低減するために Akismet を使っています。コメントデータの処理方法の詳細はこちらをご覧ください