Category: Computer

RPi4でのサーバー構築がめんどう

現在，某サーバーはRaspberry Pi 4 Model B (RPi4) 4GB RAMで，Slackware ARM (32bit版)を動かしています．

サービス内容は表向きにはWEB (https)のみで，メール (MTAとIMAPサーバー)，AFP, SAMBAなどプライベート用のデーモンがいくつか稼働しています．

RPi4はもう一台持っていて，サーバーのハードウエアが故障した時の予備的な意味もありますが，RPi4がどれだけworkstation (WS)として使い物になるかの評価に使用してきました．

今年のはじめにRaspberry Pi 5 Model B (RPi5)を中国から買って，WSの評価用はこちらを使うようになりました．

ということでこれまでWSの評価用に使用していたRPi4が1台浮いて，懸案のサーバーのソフトをRaspberry Pi OS (RPiOS) 64bitに切り替える作業に着手することにしました．ちょうど1TBのSSDも1台浮いています．

それでRPiOSの64bit Lite版（GUIなし）をダウンロードしてマイクロSDカードにコピーして起動し，ひととおり設定してからSDの内容をSSDにコピーしてcmdline.txtと/etc/fstabの内容を書き換えたらブートしました．

早速kde-plasma-desktopのインストールを仕掛けて昼食を摂り戻ってみるとファイルシステム関係のエラーがどっと出てシステムは無応答になっていました．

SSDにUSB経由で供給できる電流が足りずにdisconnectしてしまったと推測されます．

これ，5V5Aの電源に繋いでいるRPi5では起こらないです．RPi4にもRPi5用の5V5Aの電源を繋いでいますが，USBへ供給可能な電流は増えないようです．

WorkarroundはUSB-HUBをRPi4とSSDの間に入れることですが，これだけは浮いているのがないんです😅

テストのためにUSB-HUBを買うべきか，いっそもう1台RPi5を買ってしまおうか迷っています．

まだRPi5は技適を取得してなく技適マークがついていませんからWi-FiとBluetoothの使用は控えています😅
これまでも何度かやってます😅

Debian ARM64をManjaro AMD64 (x86_64)で動かす

そう，Raspberry Pi 5 Model B (RPi5)のKVM/QEMUにて，Debian x86_64を動かしたら，まあ動くには動くけど使い物にはならないという状況でした．

それではx86_64側でARM64のソフトはもう少しましに動かないか試してみました．

x86_64でKVM/QEMUを動かすのは長年Manjaro AMD64でやってきましたから，そこにRPi5のRaspberry Pi OS上で仕立てたDebian ARM64のディスクイメージをコピーして，x86_64をARM64に持ってきたときのようにまじないをかけましたが，動いてくれません．

そこでクリーンインストールをしました．ものすごく時間がかかり，ようやく動くようになりましたが，まあ動くには違いないというレベルです．stressを動かしてCPUの占有率を調べる気にもなりません😥 日本語入力環境まで試していません．

いちおう “About” だけスクリーンショットを撮っておきました．

“Processors” 欄は空白でなく，Cortex-A57をエミュレートしていることがわかります．

Ubuntu ARM64のVM動く

もう，「だったらなんだよ」って聞こえてきそうですが，Raspberry Pi 5 Model B (RPi5)のKVM/QEMU環境で，Ubuntu ARM64の仮想マシンがめでたく動きました．

CPUは3個割り当てました．UbuntuのサイトにはARM64のDesktop版のインストールイメージが見つからないので，とりあえずServer用イメージから余計なデーモンを追加しないでインストールを行いCUI環境で立ち上がるようにして，

apt install ubuntu-desktop

をして再起動したらGUI環境になりました．最初のうちは起動のたびになんかがクラッシュしたとダイアログが出ましたが，全部Noで答えて使っているうちに，クラッシュの報告もなくなり，安定してきたようです．なぜだか分かりませんが😥

“Settings” 内の “About Ubuntu” は次のように表示されます．

Processorが空欄です😥 問題なく動くので問題ないです．

このあとfcitx5-mozcをインストールして日本語入力もできるようになりました．

ちなみに，stress -c 3 で割り当てたCPU3個に負荷をかけたとき，ホストのCPUは3個がフルになって稼働しています．

左が仮想マシンのgkrellmで表示したCPUの稼働率で，上から3つ目の枠までがフルになっています．右のホストのgkrellmでは切り替わりながら4つのCPUのうち3個がフルになっている様子がわかります．

x86_64のエミュレーションでもこうなってくれればDebian x86_64(AMD64)が4倍速くなるはずです．

さて，Ubuntuの仮想マシンが使い物になるかどうかっていう総合評価ですが，Raspberry Pi 4 Model B (RPi4)やRPi5でホストOSとしてUbuntuを動かしたことがないので正確には言えませんが，今回インストールしたUbuntu ARM64の仮想マシンの体感速度と以前から試しているDebian ARM64の仮想マシンと実機の比較からして，Ubuntu ARM64もRPi4のホストOSとして動かすよりRPi5の仮想マシンのほうが速いのではないかと推定されます．安定性はまだ分かりませんが，スピード的には「使えなくない」レベルと思います．

よほどUbuntuが好きな人には，ネット情報を探してUbuntuをRPi4/5のホストOSとしてインストールするのがベターと思います．

まあ仮想マシン遊び（箱庭）が好きな人の作ってはいずれ消す箱庭の一つとするには良い景色と思います．

3個ではたしてsymmetricといえるのだろうか😥

RPi5でVM遊び (2) qemu-system-x86がマルチにならない

忍耐の限界を超える，と言いながら，その後も時々怖いもの見たさでDebian x86_64の仮想マシンをRaspberry Pi 5 Model B (RPi5)で動かしています．

先程気がついたのですが，仮想マシン側でCPUを上限の4個に設定し，実際仮想マシンでは4つのthreadをフルに使っていますが，ホストマシンではqemu-system-x86のCPU占有率は100%前後で，1つのコアしか使っていないようです．

このスクリーンショットは，仮想マシンのデスクトップの右端とその下のホストのデスクトップのデスクトップの右端で，どちらのデスクトップにもgkrellmがありCPUの動作状況などを表示しています．

左側の仮想マシンではたしかに割り与えられたCPU4個をほとんどフルに使用していますが（上4つのグラフ），ホスト側では1個のCPUがフルに使われているだけの状況（同じく上4つのグラフがCPU1〜4ですが，このスクリーンショットでは上から2番めだけがフルに稼働しています．使用されるCPUは時々で変わります）です．

もちろんネイティブのARM64の仮想マシンの場合は，仮想マシン側のCPU稼働率がそのままホスト側に反映します．

x86のエミュレーションでもホストの4個のCPUが使われれば，今のおそすぎる状況から4倍速くなることが期待できます．

しかし，ざっとネット検索したところでは解決策どころか，この状況を問題と取り上げている記事も見つかりません．

topで見ても同じです．

zram (5) resumeの問題

zramの設定について，自己完結のために記事を書きましたが，自己完結していないので補記です．

Debianのクリーンインストールをデフォルトで行うと，ルートパーティションの後ろにswapパーティションが作られてしまいます．

/etc/fstabからswapの行を削除しても次に起動するとswapパーティションが使われています．fdiskでswapパーティションを削除するという強硬策に出ると，さすがにディスクのパーティションを使用したswapはしませんが，起動がやたら遅くなります．

これは随分前から何度も経験している “RESUME” の問題です．initramsfs内の起動設定でRESUME用にswapパーティションを必要とするため，マウントしたいけどできずタイムアウトまで無駄に時間を浪費する，ということです．

仮想マシンに独自にRESUME機能をもたせても意味がありませんから（仮想マシンとしてresumeできる），ここを無効にするのですが，distroにより流儀が違うようです．

Manjaroに関しては，当blog内に記事がありました．

Debianに関しては，/etc/initramsfs-tools/conf.d/resumeの一行だけあるRESUMEの行をコメントアウトすればよいです．

3年前の記事です．何年か周期で同じことを繰り返しています😥
当然/etc/initramsfs-tools/conf.d/resumeを削除しても良いですが，残しておけば後で何かの手がかりになるかもしれません．