Rock64 + dietpi に casaOS をインストールしてみた

そろそろ synology NAS をやめようかなと考えている。現在の筐体で3代目だが、「HDD の対応が厳しくなって compatibility list 以外のものでは動かなくなるらしい」。

パッケージされているので楽なのは確かだが、正直にいうと適当なケースにボロい CPU のっけているだけで 5万円前後はするのでなんだかなーとは以前から思っていた。
適当な UI と Portainer があればいいんじゃね？と思い幾星霜。

Synology に限らず QNAP や Asustor、Netgear、UGREEN でも docker 動くものになるとこの位の価格になる。

そこでセルフホスト出来る代替品を探している。

とりあえず、手元で空いている Rock64 にインストールしてみた。

casaOS に行き着く前に Open Media Vault も試してみたが Rock64 + dietpi では自分は安定して稼働させることができなかった。ラズパイや x86 ならまた異なる結果になるのかもしれない。

インストール

インストールは公式のページ通りでOK

curl -fsSL https://get.casaos.io | sudo bash

DATA フォルダを ssd に移動する

casaOS は /DATA をデータフォルダする設定のようで、各種アプリのインストール先や、共有ファイルの置き場になっている。

今回インストールした状況では /DATA は sdカード上の別パーティションにマウントされていた。

一方、Rock64 は sd カードに diepi os をいれ boot している。

つまり、ssd にパーティション切って /DATA でマウントすれば casaOS が ssd を使うようになる。

現時点では casaOS のドキュメントはあまり充実していないので discord のアカウントを作ってコミュニティのコンテンツみないとちょっと厳しいかも。

まだ、使って数日だが、様子をみて NAS 専用機から switch しようと思う。

参考

公式: IceWhale のGithub リポジトリ一覧

User Pages | CasaOS Wiki

Rock64 のDietpi 9.15.2 でコンソールが表示されないときの対処方法

Rock64 というラズベリーパイもどきをスモールサーバとして使用しているのですが、そこで動く OS: Dietpi を新たに入れ直したところコンソール画面が表示しない現象が発生しました。

以前のバージョンではこういった現象はおきませんでしたが、インストーラーなんかも少し変わっていたので起動周りでなにか変更があったのかもしれません。

ディスプレイからは信号なしのアラートがでるので、detect を失敗しているかディスプレイが対応していないモードで出力しているのかもしれません。中華製モバイルディスプレイなので何か作りがいい加減なのが根本原因かもしれませんが、真相はわかりません。

dietpi-config でコンソールの解像度（要するに kernel の起動パラメータ）を変更出来るようなのでやってみます。

やってみるとわかるのですが、dietpi-config でリセットしてから再セットする必要があるようです。

sudo dietpi-condig でコンフィグツールを起動
1. Display Options に入る
0. DietPi-Display mode and rotation (beta) に入る
こんな項目は以前なかったと思う。
Reset を選択
<Exit> を選び再起動する
再起動後、2度目の sudo dietpi-config
1. Display Options に入る
mode に入り 1024×768 など写りそうなモードを選択する
<Exit> を選び、また再起動

この手順でコンソールを表示するようになった。

まあ、通常は ssh しかしないので画面表示できなくても問題はないが、この手の SBC は初回起動時から ssh 接続まではどうしても画面があったほうがいいので一応対処した。

最近の Raspberry OS だとそこら辺のネットワークを埋め込んで SD に焼けるので初回からディプレイなしでいけるのはいいところ、とは言え画面あったほうが便利ではある。

dietpi の mariadb にローカルからログイン

いつも忘れるのでメモ。

dietpi 公式の mariadb にはルートユーザーはコンソールにログインするときの root ユーザーとそのパスワードとなっているが、通常ユーザで ssh したコンソールでは mariadb -u root -p が動作しない。

$ sudo mariadb
とすることで mariadb のコンソールに接続することができる。

参考

Databases and Data Store Software Options – DietPi.com Docs

ラズベリーパイの RUSTDESK をヘッドレスで使う

ちょっとYAMAHA ルーターの実験をするのに、LAN の向こう側約として Raspberry PI を使っていました。

それはどうでもいいのですが、RUSTDESK をインストールし vnc をアンインストールすると、RUSTDESK で接続できなくなってしまいました。

RUSTDESK に限らず、Linux で動くリモートデスクトップ系のアプリにはよくあるのですが自分が起動したときにデスクトップ環境のディスプレイが存在しないと接続に失敗してそのまま終わるという現象ですね。

VNC の場合も基本同じ設定でいけますがラズパイの場合、インストーラと raspi-config がよしなにしてくるのでこの設定は必要ない。

参考の von的部落格でも Wayland から X11 に変更してが、たまたまそうなっていたのでそこはスルーする。

lightdm は使っていないのでここもスルー。

dummy ビデオドライバ？をインストールする。

$ sudo apt install xserver-xorg-video-dummy

; ダミーの xorg.conf を作成する
$ sudo /etc/X11/xorg.conf.d/xorg.conf

ファイルの中身は以下のようにした。von的部落格のサイトではもっと多くの解像度が定義されていたがうちにはそんな大きなモニタはないので外している。

Section "ServerFlags"
  Option "DontVTSwitch" "true"
  Option "AllowMouseOpenFail" "true"
  Option "PciForceNone" "true"
  Option "AutoEnableDevices" "false"
  Option "AutoAddDevices" "false"
  Option "IgnoreABI" "true"
EndSection

Section "InputDevice"
  Identifier "virtual_mouse"
  Option "CorePointer" "true"
  Driver "void"
EndSection

Section "InputDevice"
  Identifier "virtual_keyboard"
  Option "CoreKeyboard" "true"
  Driver "void"
EndSection

Section "Device"
  Identifier "virtual_videocard"
  Driver "dummy"
  VideoRam 192000
EndSection

Section "Monitor"
  Identifier "virtual_monitor"
  HorizSync   5.0 - 2000.0
  VertRefresh 5.0 - 200.0
  Modeline "1920x1440" 69.47 1920 1960 2152 2384 1440 1441 1444 1457
  Modeline "1920x1080" 23.53 1920 1952 2040 2072 1080 1106 1108 1135
  Modeline "1600x1200" 22.04 1600 1632 1712 1744 1200 1229 1231 1261
  Modeline "1440x900" 30.66 1440 1472 1584 1616 900 921 924 946
  Modeline "1280x1024" 31.50 1280 1312 1424 1456 1024 1048 1052 1076
  Modeline "1280x800" 24.15 1280 1312 1400 1432 800 819 822 841
  Modeline "1024x768" 18.71 1024 1056 1120 1152 768 786 789 807
EndSection

Section "Screen"
  Identifier "virtual_screen"
  Device "virtual_videocard"
  Monitor "virtual_monitor"
  SubSection "Display"
    Depth 24
    Modes "1920x1440" "1920x1080" "1600x1200" "1440x900" "1280x1024" "1366x768" "1280x800" "1024x768" "800x600" 
  EndSubSection
EndSection

Section "ServerLayout"
  Identifier   "virtual_layout"
  Screen       "virtual_screen"
  InputDevice  "virtual_mouse"
  InputDevice  "virtual_keyboard"
EndSection

RUSTDESK を初めてヘッドレスにする際は以下も必要になる。

$ sudo rustdesk --option allow-linux-headless Y
$ sudo rustdesk --get-id
$ sudo rustdeskt --password XXXXXX

rustdesk はデフォルトだと接続先の画面に表示されている接続ID とワンタイムパスワードをみながら接続する必要があるが、当然ヘッドレスだとそれができないので接続ID を取得して、固定パスワードに変更している。

$ DISPLAY=:0 xrandr --output DUMMY0 --mode 1024x768

は今回は必要なかったが、解像度変えたいときは使用すればいいってことか？

以上で無事接続できた。ディスプレイがなくても接続できる nomachine のほうがやっぱりかんたんかも。

参考

用RustDesk連線到headless的樹莓派Linux伺服器 · Ivon的部落格
中国語でしんどい、けど基本コピペでいけた

no display? · rustdesk/rustdesk · Discussion #1615 · GitHub

RUSTDESK がいい感じ

これまで linux での VNC の設定がいまだによくわからないので、nomachine をリモートデスクトップ接続に使用していました。

数あるリモートデスクトップアプリの中でも nomachine は linux, Mac, Raspberry pi, Windows に対応し都合が良かったからです。

一方で Windows ドメイン (Active Directory) に参加している Windows にリモート PC からアクセスすると度々認証まわりのエラーで接続できないことが多くちょっと面倒だとおもっていました。
具体的には設定等を変更していないのに、あるときは接続に失敗したり、別のときは成功したりといった現象にわずらわされていました。これは推測ですが、Windows ドメイン認証は、社内ネットワークに接続していない状態でPC にログインできるように認証情報がキャッシュされる仕組みがあったはずです。このキャッシュでの認証できる状態だとどうやらログインできている気がする。（反対向きにいうとネットワーク経由でログインしたときは、どうもnomachine で必要な権限が許可されていないようだ。）

話がながくなったが、上に閉口して移転先を探してみた。

候補としては、X2Go、RUSTDESK、Dayon が見つかったが今回は RUSTDESK を使用することにした。

Windows でのインストール

scoop にパッケージがあったので `> scoop install rustdesk` でインストールした。

Linux でのインストール

LM22 ではデフォルトのアプリストアに flatpak で掲載されていたので flatpak でインストールした。

2025-3-25 追記:

LM22 で RUSTDESK をインストールしただけの状態では、デスクトップセッション(X11)を開いてからしか使えないようなので、自動ログインするように設定した上で、 [Startup Applications] で RUSTDESK を起動するようにした。

Raspberry pi でのインストール

参考ページの Pi-Apps というのを経由して入れてみた。RUSTDESK 自身は github にあるんですが、Version-Upの度に手動インストールは結構だるいので、Pi-Apps を使ってみることにした。

使用方法

説明を明確にするための用語の定義

リモート PC：リモートからアクセスさせたいPC （画面なしPC や手元以外のPC）

ローカル PC: 自画面に外部PC の画面を表示してコントロールする PC

リモート PC で RUSTDESK を起動する。
- この PC をヘッドレス運用したい場合は、固定パスワードを指定する。
- リモートPC の ID とパスワードをメモる（メモらなくてもいいがこの PC の ID でリモートから接続する)
ローカル PC でも同じように RUSTDESK を起動する。
リモート PC の ID で接続開始する。
リモート PC のワンタイムパスワードか固定パスワードで認証要求をかける
リモート PC の画面が表示される。

あくまで体感でしかないが、nomachine や VNC よりもキビキビと動いているきがする。画面表示もクッキリなきがしていいかもしれない。

当面はこれを使っていこう。

参考

Install RustDesk on Raspberry Pi | Pi-Apps

rustdesk/rustdesk: An open-source remote desktop application designed for self-hosting, as an alternative to TeamViewer.

ラズベリーパイに eza をインストール

eza は ls の代替コマンドでいい感じに表示してくれるやつ。LM22 や Ubuntu では気に入って使用しているが RaspberryOS ではデフォルトではインストールできないようだ。

公式の説明では以下の通りだが、RaspberryOS (bullseye) では若干ディレクトリ構成がことなるので調整する。

$ sudo mkdir -p /etc/apt/keyrings
$ wget -qO- https://raw.githubusercontent.com/eza-community/eza/main/deb.asc | sudo gpg --dearmor -o /etc/apt/keyrings/gierens.gpg
$ echo "deb [signed-by=/etc/apt/keyrings/gierens.gpg] http://deb.gierens.de stable main" | sudo tee /etc/apt/sources.list.d/gierens.list
$ sudo chmod 644 /etc/apt/keyrings/gierens.gpg /etc/apt/sources.list.d/gierens.list
$ sudo apt update
$ sudo apt install -y eza

gpg キー用のフォルダが /etc/apt/trusted.gpg.d となり keyrings とは異なっていたので変更。

gpg キーファイル、ソースストのファイル名も eza.gpg と eza.list にそれぞれに変更した。もとの gierens という名前だと後で見たとき恐らく何ために入れたかわからなくなりそうなので変えた。
これは好みの問題で、そのままで変える必要はない。

$ wget -qO- https://raw.githubusercontent.com/eza-community/eza/main/deb.asc | sudo gpg --dearmor -o /etc/apt/trusted.gpg.d/eza.gpg
$ echo "deb [signed-by=/etc/apt/trusted.gpg.d/eza.gpg] http://deb.gierens.de stable main" | sudo tee /etc/apt/sources.list.d/eza.list
$ sudo chmod 644 /etc/apt/trusted.gpg.d/eza.gpg /etc/apt/sources.list.d/eza.list
$ sudo apt update
$ sudo apt install -y eza

eza という名前を忘れるのでエイリアスを ~/.barshrc や~/ .bash_aliases に書き込む。書き込んだら . (source コマンド) で反映させる。

$ alias ls='eza'
$ . ~/.bashrc

参考

eza/INSTALL.md at main · eza-community/eza

arm64 ROS2 環境を podman で動かす

いろいろと紆余曲折ありましたが、最終的に podman で動かすことで落ち着きそうなので記事にします。

ｄ最近の私のお供は Claude なのですが早速聞いてみますとつらつらと Dockerfile を提示してきます。多少アレンジしてますが骨子はそのままです。

FROM --platform=linux/arm64 ubuntu:22.04


ENV DEBIAN_FRONTEND=noninteractive

RUN rm /var/lib/dpkg/info/libc-bin.* && apt-get clean

# 日本のミラーに向ける
RUN sed -i 's@archive.ubuntu.com@ftp.jaist.ac.jp/pub/Linux@g' /etc/apt/sources.list

RUN apt-get update && \
    apt-get install -y wget \
    curl \
    git \
    vim \
    lsb-release \
    build-essential python3-pip python3-setuptools python3-dev \
    gnupg2 xterm x11-apps

# ROSのセットアップ（ここでは例としてROS 2 Humbleを使用）
RUN curl -sSL https://raw.githubusercontent.com/ros/rosdistro/master/ros.key -o /usr/share/keyrings/ros-archive-keyring.gpg
RUN echo "deb [arch=$(dpkg --print-architecture) signed-by=/usr/share/keyrings/ros-archive-keyring.gpg] http://packages.ros.org/ros2/ubuntu $(. /etc/os-release && echo $UBUNTU_CODENAME) main" | tee /etc/apt/sources.list.d/ros2.list > /dev/null
RUN apt-get update && apt-get install -y \
    ros-humble-ros-base \
    ros-humble-rqt* \
    ros-humble-rviz2 \
    python3-colcon-common-extensions

# 作業ディレクトリの作成
RUN mkdir -p /workspace
WORKDIR /workspace

# 環境変数の設定
RUN echo "source /opt/ros/humble/setup.bash" >> ~/.bashrc

変更かけたのは、 sed で日本のミラーに向けたところと、rm /var/lib/dpkg/info/libc-bin.* でファイルを削除した箇所です。

特にこの libc-bin.* の削除をしないと、apt-get でのパッケージインストールにことごとく失敗するします。なんとなく削除するのは良くないような気もするのですが、 Stack Overflow でもいくつか Good がついているので大丈夫じゃないかと。

setup.bash もすでに読み込み済みなので起動すると即 ros2 コマンドが実行できる状態になっています。

ビルドと起動は下のようにします。

Claud は気が利いているのどうなのかこの状態で GUI アプリも動作出来るようにしてくれているようでコンテナを実行するにはこうするみたいです。

$  ls ./Dockerfile
./Dockerfile

$ podman build -t ros2-arm64 .

$ podman run --platform linux/arm64 \
  -v /tmp/.X11-unix:/tmp/.X11-unix \
  -e DISPLAY=$DISPLAY \
  -v $HOME/.Xauthority:/root/.Xauthority \
  -v $HOME/ros2_ws:/workspace \
  --net=host \
  -it localhost/ros2-arm64

起動のたびにこのコマンド打つのはしんどいのでシェルスクリプトかなんかにしたほうがよさげ。

でコンテナの中で動作確認するには、下のようにしろと Claude が言うので試してみる。

; ホストに 目玉アプリが表示される。
in-contailner: # xeyes

; ホストに ros2 の rqt が表示される
in-contailner: # rqt

ちゃんと計測したわけではないが qemu-system でエミュレーションより少し早い気がする。

にしても Claude に言われるがままだな。

参考

Dockerのイメージビルド中でapt-getを高速化するたった1つの方法 | ゲンゾウ用ポストイット
souces.list のミラーを日本の jaist に向ける設定

ruby on rails – Docker build fails because unable to install libc-bin – Stack Overflow
libc-bin のエラー回避

Pi 5 温度の取得とシェルの小ネタ

よく忘れるのでメモ。

前回記事で、Pi5 PoE+ HAT のことを書きましたが、こいつにはファンがついていて温度設定でコントロールできるようになっています。

設定方法は、WaveShare の wiki でみればいいのですが、(多分これ Raspberry 公式と同じ内容なはずです。) ふと温度の確認方法はどうだっけと思い検索しました。

; 
$ vcgencmd measure_temp
#temp=40.1'C

; 普通に cat すると 1000 倍の値が取れる
$ echo  cat /sys/class/thermal/thermal_zone0/temp
47950

;  単純に 1 / 1000 にすると切り捨てられる
$ echo $(($(cat /sys/class/thermal/thermal_zone0/temp) / 1000))
47

; こうすると、小数点以下が生きる
$ cat /sys/class/thermal/thermal_zone0/temp |awk '{print $1 /1000}'
47.95

参考

RaspberryPi(Raspbian)のCPUの温度をcatを使わないで取得してみた #Bash – Qiita

Pi5 に PoE+ HAT で NVME 起動するように設定する

先日から始まった ROS2 関連のエントリになります。

とりあえず ROS2 を Raspberry Pi で動かしているのですが、Pi 4 が 1 台だけだと心もとないので Pi 5 用の POE+ ハットを購入して動かすことにしました。

買ったのは WaveShare の PoE M.2 HAT+ という商品です。日本だと 4,000 から 5,000 円くらいで入手できると思います。自分は WaveShare 公式から買いました。

そんなことはどうでもいいのですが、この HAT には M.2 NVME ソケットがついていて SSD を接続するとそこから Pi 5 を起動できるようになります。というのも ROS2 のモジュールを作る際、ビルドが早い環境があったほうが何かと都合がいいので SSD 起動を試します。

基本、参考セクションの公式のページ通りにやれば何も問題は起きないはずです。が、自分の場合はなぜか pcie デバイスとして認識しない事態になりました。

というのもこの HAT のケーブル向きがあるんです !

写真は最終的に成功したときの様子です。

接続がうまく行っているときは右上の赤枠の通り、電源 LED が点灯し、緑のアクセスランプが適宜点灯(要するに点滅)します。

で前述のケーブルの向きですが、こうなります。

PoE M.2 HAT+ ではケーブル向きを上の写真のように三角の位置を揃える必要があるってことです。

これ普通に公式 Wiki 見ていればきづくはずですが、フラットケーブルの端子面は気にしていたのですが、見落としてました。

一般的に片面にしか端子がないフラットケーブルはひっくり返すと通電しません。(コネクタ側も片面しか端子がないので、当たり前です。)

さらに、この HAT の場合には、三角マークの部分で左右非対称になっているようで三角の位置を合わせないとダメでした。つまりこのケーブルは、Pi 5 に挿す側と HAT に挿す側が予め決まっており、裏表も正しく挿す必要がありました。

同様の事態になる人は少ないと思いますが、自戒の意味を込めて晒します。

あとは、まあ公式通りです。

/boot/firmware./config.txt に dtparam の行を追加します。

$ sudo vi /boot/firmware/config.txt
[all]
dtparam=pciex1
dtparam=pciex1_gen=3
:wq

動画かなにかで [cm4] セクションに書いている例もありましが、なんとなく気持ち悪いので [all] セクションに書きました。正直無名セクションや、pi0 系のセクション以外ならで良いとおもいますが。。。

再起動して lspci で SM2263 が表示されれば OKです。

次に rpi-eeprom-config –edit でブートオーダーを変更します。

$ sudo rpi-eeprom-config -edit
BOOT_ORDER=0xf416

あとは、”SD Card Copier” でコピーするなり、”Raspberry Pi Imager” で SSD にOSを書き込めば起動します。

参考

PoE M.2 HAT+ – Waveshare Wiki

Raspberry Pi 5をNVMe SSD起動でデスクトップPC化

Ubuntu 22.04 で Unable update “Snap Store”: といわれアップデートできない

先週から ROS2 をラズパイ 4 で動かし始めています、ROS２の対応 OS が Ubuntu 22.04 なので RaspberryOS を諦めて素直に U22 にしています。

同じ Debian 系とはいえ普段使っている Linux Mint とも RaspberryOS ともビミョーに異なり、困らないもののストレスフルな毎日です。

表題ですが Snap Store (Ubuntu Software) で Snap Store のアップデートがあるので更新しようとしてもエラーメッセージ「Unable update “Snap Store”: snap … 」とでてアップデートできません。試しに再起動を試みましたが現象変わらず。

以下のコマンドで回避できました。

$ killall snap-store
$ sudo snap refresh snap-store

Ubuntu は多分 Gnome でつかっているんだけどやっぱり遅くてあまり好きになれない。ROS２動かす GUI はいらないのだけど、カメラのデータを扱いたいのでぱっと確認しやすい GUI ありのがいいのよね。

参考

How to close the Snap Store to allow Snapd to update it – Project Discussion / Snap Store – Ubuntu Community Hub

WPP

WPP