バックアップディスクが不調になったのとほぼ同時にDebianがブートしなくなったのは偶然ではない

何言ってるか解らない題だと思いますが,自分宛のメモです.

現在Linux WSの第1 OSはManjaro,第2 OSはDebianです.両OSは同じ1TBのSSDのパーティションにあります(だいたい半分ずつ).このほか仮想マシン(KVM/QEMU)のディスクイメージを保存するのに2TB SSDを,そのディスクイメージをバックアップするために3TB HDDを,ManjaroとDebian本体をバックアップするのに2TB HDDを使用してきました

そのバックアップ用の2TB HDDが数日前から不調で,バックアップのためマウントしようとしても出来ません.取り出して外部のSATA用のアダプターに接続したら読み出すことが出来たので,手持ちの1TB SSD 2基に中身をコピーしました.

この不調が生じたのとほぼ同時期からDebianがブートしなくなりました.

よく考えてみると,Debianはバックアップ用のHDDの第1パーティションをEFIに使っているのです.メインOSのManjaroが自分のドライブの第1パーティションとしているのでDebianはそこを使えないためです.

もちろんManjaroのEFIから導かれたGRUBにはDebianも表示されますが,Debianが主体のEFI/GRUBがあった方が便利です

このため,DebianのEFI/GRUBが置かれたバックアップ用の2TB HDDが不調になったらDebianはブートできないのです(起動時にマウントすべきEFIパーティションが見つからないため).

2TB HDDの後任には2TB SSDを新規購入してあてがいました.今どき2TBだとSSDはHDDとほとんど値段が変わらなくて驚きました.

故障したSeagateの2TB HDDと新規購入したOricoの2TB SSD

2基の1TB SSDに待避したバックアップの中身を新規購入したSSDへコピーしましたが速いです.なんか,バックアップ用にするのはちょっともったいない気もします.

4基ともPCの筐体内に設置してあります.
とはいえなかなか煩雑ではあります.

zram (6) 小メモリーには不適かも

これまでZRAMを信奉して,現在使用している全てのLinuxの実マシン(Manjaro AMD64, Debian AMD64, Raspberry Pi 3/4/5 Model B)と仮想マシン(AMD64, x86 32bit各種ディストロ)に採用してきました.

それらでは特に目だった問題はなく,パフォーマンス的にもファイルやパーティションを使用するものより少なくとも悪くはないと感じています

現在ちょっとしたきっかけがあってRaspberry Pi Zero 2 WHで遊んでいます.

Raspberry Pi Zero 2 WH

今日のわが家でRaspberry Piが担う一番の仕事は,防犯カメラの出力するRTSPをHDMI端子でつないだ地デジテレビに再生することです.

紆余曲折ありましたが,現在はVLCを使うことに落ち着いています.この仕事はRaspberry Pi 4 Model B (RPi4)ならば余裕です.何日間も安定動作してくれます.

Raspberry Pi 3 Model B / B + (RPi3/RPi3+)では良くて一日持つくらいで,たいてい一日に2〜3回VLCが落ちます.筆者はともかく家族が利用するには不適です.

それでRaspberry Pi Zero 2 (RPi02)ではどうかというと,数時間もつこともありますが,数分で落ちることもあります.

それが,ZRAMでは全然だめで,そもそもVLCが起動しません.Raspberry Pi OSのデフォルト設定である/var/swapを使用したファイル swap (dphys-swapfile)ではその数分から数時間という状態です.

RPi02のCPUはRPi3と同じARM Cortex-A53でクロックが1200→1000MHzに落とされているのが違いなのでたぶんメモリーが少なすぎることがこの安定性の差だと思われます.

ひょっとすると,RPi3 (+)の現在の不安定性(1日に2〜3回VLCが落ちる)もZRAMからdphys-swapfileに戻すと解決するかもしれないのでやってみます.

ただし,客観的に示せるようなデータはないです.

Manjaroの弱点

筆者の愛用しているManjaroはrolling release modelというバージョンアップの方法を採用しています(ベースのArch Linuxがそうであるため).

まあ,GentooSlackware-currentも同様ではあります.この手のdistroの弱点は,しばらくupdateをしないで放置しておくと通常のupdateの手段ではupdateができなくなってしまうことです.

実マシンから作ったディスク仮想イメージとして存在させている仮想マシンは,もとの実マシンのバックアップ的な意味合いなので存在感が薄く,気がつくと最後の更新が何か月も前だったりします.

筆者のLinux第一WSであるManjaro AMD64も,ときどきバックアップのためにディスクを仮想化して仮想マシンに仕立ててます.仮想マシンとしても実は一番気に入っているので,Mac mini2台と実マシンであるManjaroのWS自身の中で仮想マシンとして “飼って” います.

気に入っているとは言えバックアップなので新し味がなく,ときどきupdateが何か月ぶりになってしまうことがあります.そんなときは他のupdate可能なイメージをコピーしたり,新たに実マシンから仮想化しました.パックアップの更新としての意義があります.

たまたま,前日updateができなくなった状態をあるSNSに投稿したら,親切な方が,

pacman-key --refresh-keys
pacman -Sc

を試してみてはと教えてくださいました

一台目はそれで復活しました.しかし,別の仮想マシンが同様の症状になっていましたが,上記の方法では復活できませんでした.1勝1敗です.

NGなほうはさらに別のマシンで動いているupdate可能なManjaroのディスクイメージをコピーして差し替え,動くようになりましたが,バックアップの意味を込めて後で久しぶりに実マシンから仮想化しようと思います.

筆者はシステムのメンテはrootでログインした状態で行うことをポリシーにしています(Slackware流)ので,コマンドごとにsudoを使う事はしません.

DOSBox-XでLog200

DOS用LogソフトLog200をWindowsのDOS窓以外で動かす取り組みですが,Slackware64 (AMD64)のDOSEMUのもとで,Log200を動かして,Slackware ARM (32bit)のサーバー上にあるデータファイルはNFSでアクセスしよう,ということにしました.DOSEMUはmacOS上で動くVMWare Fusionで動くSlackware64でも動きますし,そこからNFSでサーバーのディレクトリーをマウントすることもできますから,仮想マシンと実マシンのいくつかの環境からLog200を実用的に使えます

いちおうこの状態を結論としていました.

ところが先日,親切な通りすがりのかたが,DOSBox-XのDOS/VモートでLog200が動く可能性が高いとアドバイスしてくださいました.

さっそくDOSBox-Xがインストール済みなmacOS (x86_64 Sonoma 14.5, x86_64 Ventura 13.8.7)で試したところ,あっさり動きました.通りすがりのかたに教えていただいた通り,基本的に設定ファイルである “dosbox-x.conf” に,

[dosv]
dosv=jp

と書くだけで自前でDOSを用意する必要さえもありません.

macOS Ventura (x86_64 13.8.7)上で動くDOSBox-Xで動くLog200 (DOS版)

以前調べたところではDOSB0x-Xは,Debian (Raspberry Pi OS)やManjaroでは公式チャンネルからの配布はありません.代わりにFlatpakというパッケージマネージャーでインストールすることになっていて,今回あらためてインストールしたところ,日本語DOS/Vモードがちゃんと動き,Log200も問題なく動きました.

Raspberry Pi OSにインストールしたFlatpakで動くDOSBox-Xで動くLog200

Flatpakでうまく行った環境は,

  • Manjaro AMD64
  • Raspberry Pi OS (64bit)

です.あっさり書いちゃましたが,非x86のRaspberry Pi OS(Raspberry Pi 5 Model B 8GB RAM)でも簡単に,しかも実用上問題ない速度で動きました.

Raspberry Pi OSで動きますから,Debian AMD64でも間違いなく動くでしょう.

最終目標である,Slackware ARM (32bit)ですが,もちろん公式配布パッケージにDOSBox-Xは含まれていませんが,SlackBuildsにはあるので,sbopkgでインストール可能な可能性があります.一方SlackBuildsにはFlatpakもあります.

他にFlatpakで動かすアプリがいくつかあれば先にFlatpakを試す価値はありますが,いまのところDOSBox-Xだけですから,先にDOSBox-Xをsbopkgでbuildするほうがいいだろうと判断してそうしました.

で,buildできて動きました

Slarckware ARM (32bit) 15.0にsbopkgでインストールしたDOSBox-Xで動くLog200 DOS版

いよいよSlackware ARM64 15.1のリリースが待ち遠しいです.

仕立ててはいませんが,Manjaro AMD64をホストにしてSlackware64のゲストからも同様にLog200は動かせます.
MacPortsによる.
buildには少々時間がかかりますが.

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のものか新規に購入するかは未定.