Raspberry Pi OSぶっ壊す

Raspberry Pi OS(RPiOS) 13 Trixieがリリースされたようで,喜び勇んでRaspberry Pi 5 Model B (RPi5)のメインOS(RPiOS+KDE Plasma Desktop)をupgradeしました.

ぶっ壊れました😓

SDカードベースのサブOS (RPiOS+PIXEL Desktop)で試しましたが,やっぱり壊れました.libgtk-3.0関係の依存性に問題があるようです.

Debian AMD64 (x86_64)を試してみよう.でもまた壊したらたいへんだ,ということで,仮想マシンのsnapshotを保存してからupgradeしたところ,多少のWARNINGは出ましたが,大きな問題なくupgradeできました.

引き続き実マシン(第2WSであるx86_64マシンの第2OS)もupgradeしたらやはり同様にWARNINGでますが,本質的なupgradeは問題なしでした.

未来の自分宛教訓

今後Debian / Raspberry Pi OSのmajor upgradeの場合は次の順番でupgradeする.

  1. Debian AMD64 (x86_64)の仮想マシンについてsnapshotを保存してから
  2. Debian AMD64の実マシンについて,backupを取ってから
  3. SDカードベースのRaspberry Pi OSについて,SDカードの内容をコピーしてから
  4. SSDベースのRaspberry Pi OSについて,backupを取ってから

M4 Mac mini来ました

外箱を開けたところ

何とか資金の見通しが立ったのでApple Storeに注文して,本日届きました.ベースのマシンにRAM, SSDましましで,倍くらいになってしまいました😓

まずはこれまで使っていたIntel Mac mini (Core i7 6-core)のSSDを外部のSSDにクローニングし,終わったら電源を落としてビデオやUSBの接続を全部外して新しいM4 Mac miniにつないで電源を入れました.その際,M4 Mac miniはUSB-Cのポートしかないので,死蔵していたUSB-C → USB-Ax4のハブを使いました.

奥にあるのがUSB-C → USB-A x4ハブ

起動すると移行の手続きに入ります.電源を入れると,Thunderbolt → HDMI変換ケーブルでつないであるメインモニターが認識されないので仕方ないから少々狭いサブモニターで作業しました.またKVMスイッチ経由でつないでいるキーボードも認識されませんので,これも仕方ないからキーボードを前述のUSBハブのもう一つ下流のUSBハブにつないだら認識されたのでそのまま進みました.

SSDはつなぎっぱなしだったので移行元のリストに出てきてそのまま全部移行しました.それから1時間ちょっとで移行が完了しました.

移行中

メインモニターを認識させるのに結局Mac miniのHDMIポートを使うことにしました.サブモニターはUSB-C (Thunderbolt) → Apple Thunderbolt変換アダプター → Thunderbolt Doc → HDMI というこれまでIntel Mac miniでつないでいたままの形で使えています.

ほとんどのアプリは既にApple Siliconのバイナリーが同包されている “Universal” なのでサクサク動きます.VMWare FusionもUniversalですが,仮想マシンは動いてくれません.

注(2025/08/09) : この件,前面のUSB-Cの2portはUSB-3.xのサポートのみでThunderbolt/DisplayPortのサポートがないためです.背面ならば使えることを確認しました.

3プロジェクト進行中

つくづく自分はコンピューターとネットワークがあれば生きていけるんだなあと思う今日この頃です😓

さて,現在3つのプロジェクトが進行中です.

メインWSのリプレース

メインWSは現在史上最強のIntel Mac miniです.Mac mini最初で最後のデスクトップIntel Core CPUを搭載したMac miniで,しかもCore i7にCTOしてますので,間違いなくIntel Mac miniとしては他に右に出るものはありません.

たしかに抜群のパフォーマンスでしたが,Apple Siliconと比較すると何分の1も遅いようですし,いよいよ次のmacOSのメジャーリリースmacOS 26では対象外となるようなので,ここで最新のMac miniを導入しようと画策中です.

まあ,このプロジェクトはその購入資金をいかに用立てるかということが主で,技術的な要素はあんまりないです😓

Webサーバー/プライベートサーバー更新

現在Raspberry Pi 4 Model B (RAM 8GB)でSlackware ARM (32bit)を走らせています.Slackware ARMは15.0が最新で,いろいろ陳腐化してきています.たぶん15.1(または16.0)のリリース時にはSlackware ARMプロジェクトもaarch64版を出すと思うのですが,いつになるか解りません.

そこで,素直にRaspberr Pi OS 64bitに移行します.必要なデーモン類についてはセキュリティー上詳しく書きませんが,まあ何とかなるとは思います.

ただ,Linuxサーバーの更新は気合いが必要なのでそれが心配です.

ハードウェアとしては現在予備役のRapsberry Pi 4 Model B (RAM 4GB)を使用して立ち上げようと思います.必要なUSB HUBも入手しましたし,ルートドライブとする予定の1TB SSDも確保済です.

それと置き場所がないのでWindow 10 32bitで使っていたデスクトップPCを廃棄します.メーカーのクレバリーが倒産してしまったのですが,PCリサイクル料金は払っているので,PC3R : : 一般社団法人 パソコン3R推進協会に申し込めば何とかなるようです.

そうしたスペース,設備的な整備の後,気合いが出るかというプロジェクトです.

門柱灯サイバー化計画

これが一番面白みがあるプロジェクトです.現在門柱にセットした防犯カメラはLEDの門柱灯の電源にACアダプターを付けて供給しています

現在の問題点は,

  • 屋内にあるWi-Fiルーターとの接続がぎりぎり
  • 門柱灯を24時間点けっぱなしにするとセキュリティーが甘いと見られかねないので,朝夕門柱灯はOff/Onしていますが,それだと防犯カメラもその時間しか動かない

の2つがあげられます.これを解決するために,

  • 屋外にWi-Fiルーターを設置する
  • 門柱灯を自動的にOn/Offする仕掛けをする

ことが必要です.

セキュリティー上詳細は書けませんが,一番チャレンジングです.

購入代金に含まれています.
第二種電気工事士の有資格者です.資格の範囲の工事です.

バックアップディスクが不調になったのとほぼ同時に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 (7) 小メモリーも設定次第かも

手持ちのRaspberry Pi (RPi)のうち,RPi 3 Model B (RPi3)と,RPi 3 Model B+ (RPi3+)はメモリーが1GBです(実際はどちらも900MB強).またRPi Zero 2 WHは500MBです.

メモリーが小さいRPiは,ZRAMのサイズを100%〜120%にしていました.しかしどうもこれが負担のようで,RPi3, RPi3+ともVLCが1日以上安定してRTSPを再生することが出来ません.それで,小メモリーにZRAMは不適といったんは結論づけました.

しかし,RPiでVLCを使ってRTSPを再生するにあたり,SWAPが500MB以上必要なケースはないようです.少なくともdphys-swapfileでは初期値が512MBで,動作状況を見てもSWAPの使用が300MBを超えることはないです.

ということで,ZRAMについてもSWAPの容量は400〜500MBで良いのではないかと思い,現在主記憶の50%という設定で動かしています.今のところRPi3もRPi3+もまる1日以上安定してVLCがRTSPを再生し続けています.

ところで,RPi Zero 2 WHですが,こちらは主記憶が500MBで,VLCでRTSPを再生するとSWAPの領域は200MBを越えますので,おそらくZRAMの領域を主記憶の50%としたところで安定性は戻らないと思います.そもそもdphys-swapfileでも安定しませんし.

ということで,RPi3およびRPi3+についてはしばらく50%でZRAMの試用を続けます.RPi Zero 2 WHについては門柱灯を日の出,日の入りの時刻にOFF/ONする門番の役目を与えることにします.