Manjaro ARMのRPi5 kernel

Raspberry Pi 5 Model B (RPi5)の評価はその後も続けています.テストしているのはRaspberry Pi OS (RPiOS), Manjaro ARM(64bit), Slackware ARM64 (Slackware-current)の3OSで,そのうちのRPiOSとSlackware ARM64はRPi5を入手した2024年初時点でRPi5をサポートしてました

Manjaro ARM64は一番使いたかったOSでしたが,当時は公式にRPi5をサポートしておらずどうしたものかとヤホーで検索したところRPiOSのKernelとモジュールなどを使えばよいと知りその状態で動かしてきました

その後4か月も経つので正式Kernelもあるだろうと,PacmanのGUIフロントエンドであるAdd/Remove Softwareの検索窓に “rpi5” と入れて検索したら,Kernelなどがあることが解り,早速インストールしました.

ネットで調べたところ本年3月には公式Kernelがあったようです.まあ,Manjaro ARM64がRPi5で動かせていたので今更どうでもいいですが😅

今後,ないとは思いますが,RPi4で使うことも考えて,RPi4用のKernelなども残しました.削除するのは簡単ですし.

今までのところ,RPi5上でRPiOSとManjaro ARM64は十分使える感じです.

Slackware ARM64に関しては,Slackware-currentであるため,ほとんど毎日のようにいくつものupdateが来て,サーバーがあまり強力でないこともあって,その度にupgradeにものすごく時間がかかります.その事もあっておよそ使いやすいとは言えません.

現在の “結論” 的には,Slackware ARM64の15.1 (次期公式リリース)が出るのを待って,RPi5にインストールして,次期サーバーに仕立てます.

Slackware ARM64は,SARPi5により.
本当はGoogleです.
slackpkg upgrade-allをかけたまま就寝することが多いです.
現在使用している8GB RAMのものか新規に購入するかは未定.

Manjaro AMD64 ぶっ壊す

Workstation (WS)をぶっ壊すのは日常茶飯事ですが,これまであまり壊すことのなかったManjaro AMD64 (x86_64)をぶっ壊しました.

先日Manjaro AMD64がKDE Plasma Desktop 6にupgradeされて喜んだのですが,どうもzramがぶっ壊れているのに気が付きました.

色々調べて,systemd-swapが機能していないことがわかりました.systemctl statusで見ると,sysv_ipcがインポートできないことがわかりました.

更に調べると,このsystemd-swapはout-of-dateとなっていることがわかりました😥

それで,Archlinuxのzramのドキュメントを読みながら色々やっていたのですが,どれをやってもうまく行かず,挙句にはEFIをぶっ壊して起動しなくなってしまいました.

EFIがぶっ壊れてはサブWSであるSlackware64もブートできず,にっちもさっちも行かない状況に陥りました.

まずは,Slackware64のブート用USBメモリーから起動して,Slackware64のEFIとGRUBを直して起動するようになりました.ここまでは大した手間ではありませんでした.

このあと,Manjaroのパーティションに4月のバックアップをrsyncでコピーしましまたがうまくブートしません.libvirdがどうのこうのいう,本質的には関係ないエラーなんですが,そのエラーの先に進んでくれません.念の為,Manjaroのパーティションをformatしてからrsyncしましたが,同じ結果でした.

しかたないので,libvirtdを起動しないようにしてある仮想マシンのイメージからrsyncをかけたら,ようやくブートしました.

どうも,rsyncで差分をバックアップしたものからの復元はこのManjaro AMD64に限ってはうまくいかないようです.もちろんあるサブディレクトリー以下とか,特定のファイルについては簡単に復元できるのでバックアップを取る意義はありますが,まるまる起動可能なバックアップとして今までより頻繁に仮想マシンの仮想ディスクにクローニングすることにします.

まともに動くところまでロールバックしたところで,systemd-swapを消して,もう一度,Archlinuxのzramのドキュメントを読みながらやり直します.

udevルールによる方法

結局うまく行ったのは,Archlinuxのドキュメントのうち,udevルールを使う方法です.手順としては,

  1. これまで使っていたZramのサービスが起動しないようにする
  2. /lib/mdoules-load.d/zram.conf に, zram の一行のみ書く
  3. /lib/modprobe.d/zram.confに, options zram num_devices=8 の一行のみ書く
  4. /etc/udev/rules.d/99-zram.rules に,
    KERNEL=="zram[0-7]", SUBSYSTEM=="block", DRIVER=="", ACTION=="add", ATTR{comp_algorithm}="lz4", ATTR{disksize}="1024M", RUN+="/sbin/mkswap $env{DEVNAME}"
    の一行のみを書く
  5. /etc/fstabに,
    /dev/zram0 none swap defaults,pri=100 0 0
    /dev/zram1 none swap defaults,pri=100 0 0
    /dev/zram2 none swap defaults,pri=100 0 0
    /dev/zram3 none swap defaults,pri=100 0 0
    /dev/zram4 none swap defaults,pri=100 0 0
    /dev/zram5 none swap defaults,pri=100 0 0
    /dev/zram6 none swap defaults,pri=100 0 0
    /dev/zram7 none swap defaults,pri=100 0 0

    を書く
  6. 祈りながらリブート

だったと思います😥

1のあとの再起動で,zramモジュールがロードされていないことを確認,3の後の再起動でzramモジュールがロードされ,4のあとの再起動で/dev/zram0〜7ができていることをそれぞれ確認,など途中要所要所で動作確認をすると着実に進められます.

以上,未来の自分あてのメモでした.

厳密には,メインWSはMac miniで,Manjaro AMD64がサブWS,Slackware64の実マシンはサブサブWS,またはサブWSのサブOSです.
かんたんに書いてありますが,rsyncののち,chrootして,efibootmgrやgrubのツールを使って起動するように呪いをかけます.

KDE Plasma Desktop 6

いくつか動かしているLinuxの実マシン・仮想マシンでは,UbuntuとRaspberry Pi OSの一部のマシンを除いてデスクトップはKDE Plasma Desktopにしています.

先程updateをかけたら,Manjaro AMD64のデスクトップが,KDE Plasma Desktop 5から6にupgradeしました.

Debian AMD64はまだ5のままです.

Manjaro ARM64のKDE Plasma Desktopが6になるのが楽しみです.

Bochsメモ (2) KVM/QEMUでやってみる

Isn’t Wayback Machine Great!

しばらく直接は取り組んでいませんでしたが,段取りを考えたり,若干の調べものはしてました.

まず,現在,Bochsを中心に進めていく方針に対して大きな懸念材料があります.それはDOSのコンソールから “:” が入力できないことです.これは,とてもプリミティブな問題で解決方法があるはずと思い調べたり心当たりを試しましたが,解決できていません. “:” をキーボードから入力できないというのは, DOSの作業においては致命的です.

そこで,代替案として,KVM/QEMUでやってみよう,ということを考えています.

なお,今回FreeDOS/V + 鳳のインストールイメージを発見できました.Wayback Machineに当該のページを見つけました.

フロッピーイメージも収録されています.ただ,自己展開のexeとかLHA形式とか今更どうするんだって思いましたが,このファイル名から自分のSSDのどこかにあるだろうと,

locate fdos0138

で探すと,展開済みのfdos0138.imgが見つかりました.タイムスタンプは,2006年1月2日なので,間違いなくオリジナルを展開したものとわかります.Wayback Machineを参照しなかったら,ここまでの進展はなかったです.

このイメージをフロッピーイメージとして,新しく仕立てるKVM/QEMUの仮想マシンにつなぎ,bximageで用意した仮想ディスクもつないで,ああだこうだしてみようと思います.

結局,最初のKVM/QEMUに戻るわけですが,うまく行かなかったら,第二案としてBochsでなんとかならないかやってみます.

xzにsshのバックドア

久しぶりにセキュリティー界騒然の事態ですね.劇場型のやり取りなどで3年がかりでxzのメインテナーに加わった人物がxzにsshのバックドアを仕組んだそうで,スパイ映画さながらです.

問題になるのは,xz (liblzma) 5.6.0と5.6.1だそうです.日常的なファイルの圧縮展開に利用されるばかりでなく,圧縮効率が高いため多くのdistroがパッケージをxzで圧縮して配布していてます.

手元のMac miniではMacPortsを使っているのでxzが入っているはずです.調べてみると(注意: xzコマンドを発行してバージョンを調べるのは危険かもしれません),

まさにドンピシャのものが入ってました.早速,

port selfupdate
port upgrade outdated

をかけたら,安全とされる古いバージョンに戻りました.

ちなみに,手元のいくつかのdistroで調べたところ,Slackware64とARM (32bit)の15.0は5.2.5で問題なし,Debian BookwormとRaspberry Pi OS Bookwormも5.4.1で問題なしですが,ManjaroはAMD64, ARM64とも5.6.1で今のところupdateは来てません(2024年4月4日09:35JST現在)

圧縮のスピードはかなり遅いですが😅
ただし,Slackware AArch64 currentは5.6.1です.他のアーキテクチャーのcurrentも5.6.1の可能性が高いです.
Manjaroは配布パッケージの圧縮にgzipを使っているようなので.ユーザーがxzをなにかの目的で使わなければ大丈夫なのかもしれません.