RasPiでDebian使いたかったらRaspberry Pi OS

何がしたいかというと,Raspberry Pi 4 Model B (RPi4)でDebian + KDE Plasma Desktopを動かし,fcitx5+Mozcによる日本語入力をしたいというのが最終目標です.

紆余曲折

この節は,他の人,というか自分自身にとってもなんの役にも立たない愚痴です

そもそもなんでRaspberry Pi OSでなくてDebianなのかというと,Raspberry Pi OSの標準DesktopであるPIXELが気に入らんのです.なんとしてもManjaro ARMのように,KDEを動かしたいのです.「だったら,Raspberry Pi OS LITEをインストールして,そこにKDEをインストールすればいいじゃないか」,と思った人は正解です.昨年の6月に私もそれに気がついて,やっていたんです.

しかし,今回なぜすぐにそれをしなかったかというと,Debian Bookworm (12)がリリースされたのが今年の6月10日であるのに,Raspberry Pi OS Bookwormは10月11日です.これは本家を使わなければ時代から取り残されるとの危機感を抱いたのです.

そこで,DebianのサイトにあるRasperry Pi用イメージを試してみましたができがよろしくない.これは好事家によるcontributionなのであまり文句はいってはいけないようですが,起動が遅いうえ,USB-3接続のSSDにインストールすると,upgradeができないという致命的な問題がありました

そこで,Debian ARMの公式のインストールDVDイメージをダウンロードしてドキュメントの初めの方を読んでみましたが,基本的にUEFI対応のハードウエアでないとDVDイメージは使えず,Raspberry Piのようなそうでないハードウエアに対しては,自分でなんだかんだとインストーラー的なものを作らないといけない.

そう,それをやっているのがRaspberry Pi OSのcontributerたちなわけです.寄ってたかって作っているわけですから,好事家の私家版が及ぶ訳はないし,ましてや筆者ごときが逆立ちしたってそれより良いものは作れないわけです.

というあたりをこの週末の作業で悟ったり思い出したりしたわけです.

RPi4でKDE + Mozc

Raspberry Pi OS Lite (64bit)をインストール

説明はいらないと思います.Liteなら数GBのSDカードにコピーできそうですが,手持ちの関係で32GBのmicroSDカードを使いました.

最初の起動では,色々設定があり,素直にしたがって設定をします.その後の起動でネットの接続を確認して,apt update; apt upgradeをかけました.

SSDへのコピー

SSDへのコピーのタイミングはいつも迷いますが,早いほうがupgradeや新規インストールの作業が高速なのは言うまでもありません.しかし,あまり早い段階ですると,そこから先は製作元の想定していない使い方なのでトラブルが発生するリスクが高くなります.

しかし,KDEのインストールでは1000以上のパッケージがインストールされるので,この段階で移行しました.

ご存知のようにRPi4では,USB接続したHDD/SSDからブートも可能ですが,SSDの第1パーティションをManjaro ARMのブート用のままにして,SDカードを差すと第3パーティションをrootにしてDebianが起動するようにしました.

この場合,32GBのSDカードをそのまま使うこともできますが,もったいないので手持ちで一番小さい2GBのmicroSDカード(以下 “小SD(カード)” )をブート用に仕立てました.

ここまで使用してきたSDカードのルートから,Debianが活きたままSSDにコピーすることもできますが,その場合あとでいくつか呪い(まじない)が必要なので,他のLinuxマシンで死んだ状態のSDカードからコピーしました

コピー先は,SDカードの第1パーティションは,MBR式パーティションの小SDカード(vfatのパーティション一つだけ)のvfatパーティションへ,SDカードの第2パーティションの中身はSSDの第3パーティションへ,です.

コピーコマンドはいずれも,

cp -Rdvp  元  先

または,

rsync -artlvd --delete  元  先

です.

Raspberry Pi OSはデフォルトでパーティションラベルでパーティションの識別をしているので,それはそれで楽なので,fatlabel, e2labelコマンドで,起動用の小SDカード,rootパーティションに適当な名前を付け,ブート用小SDカード内のcmdline.txtとrootハーティションの/etc/fstabのそれぞれの該当部分を編集します.

あとは,起動用に新しく仕立てた小SDカードとSSDを接続して,祈りながら起動します.間違いがなければ起動するはずです.

KDE Plasma Desktopのインストール

無事起動したら,いよいよGUIのインストールです.メインというか,root以外の唯一のユーザーでログインして,あとはSlackware的流儀で行くためすかさずsudo -iをします.

まずインストールするのは,sddm, kde-plasma-desktopです.今回はsddmを明示しましたが,いらないかもしれません.

次に,kde-fullです.完了したら,また祈りながらリブートですが,sddmが起動してくれませんでした.

sddm workaround

RPi4を起動しても,sddmが起動してくれません.CUIのコンソールから(root権限にて),

systemctl start sddm

とすると,sddmが起動してKDE Plasma Desktopにログインできますから,なにかタイミングの問題と思われます.

systemctlで,sddmdisableにしてから再度enableにしたり,sddmパッケージを削除して再インストールするというようなオーソドックスな方法を試みましたが,改善しません.

実は,/usr/lib/systemd/system/sddm.serviceに解決のヒントが書いてあります.

略
# If using tty1 and plymouth, sddm will fail till plymouth stops
# consider using:
## After=plymouth-quit.service
# or to forcefully stop plymouth and start earlier:
## Conflicts=plymouth-quit-wait.service
## After=plymouth-start.service plymouth-quit-wait.service
## OnFailure=plymouth-quit.service
略

ところがどっこい,提案してあるどちらを試しても状況は変わらずでした

さて,何をいつまで待てば良いかわからないので,単純に30秒待つことにしました.

具体的には,/etc/systemd/system内に,次の内容で,テキストファイル,sddm.timerを作成します.

[Unit]
Description=Delayed start of sddm

[Timer]
OnBootSec=30sec

[Install]
WantedBy=timers.target

CUIから,

systemctl disable sddm
systemctl stop    sddm   ← 念のため
systemctl enable  sddm.timer

ここで,リブートして,動作確認します.筆者の環境ではうまくいっています.

その後,待ち時間を削り,最終的にOnBootSec=0secにしてもsddmが起動します.

日本語環境

Mozcをインストールする前でもあとでもいいですが,/etc/X11/xorg.conf.d00-keyboard.confというテキストファイルを以下の内容で作ります.ローマ字入力の人には関係ないかもしれませんが,これをしないと,あとでKDEのsettingでどこをどうしてもかな入力で濁点や半濁点,長音記号が使えなくなります.

Section "InputClass"
    Identifier "system-keyboard"
    MatchIsKeyboard "on"
    Option "XkbLayout" "jp"
    Option "XkbModel" "jp106"
    Option "XkbOptions" "terminate:ctrl_alt_bksp"
EndSection

fcitx5-mozc

apt install fcitx5-mozc

して,一般ユーザーのホームディレクトリーに,.xprofileという名前で,

export GTK_IM_MODULE="fcitx"
export QT_IM_MODULE="fcitx"
export XMODIFIERS='@im=fcitx'

が中身のテキストファイルを作ります.たぶん,sddmの再起動だけで良いと思いますが,システムごとリブートして確認してみます.

あとは,KDE settingsのキーボード設定やMozc設定や他なんやかんやで使えるようになると思います.

経緯の記録くらいの意味はあるかもです.
LXDEからの派生.
厳密に言うとapt upgradeすると,起動しなくなる.
あくまで当社調べです.
いや,世の中一人ですごいことをする天才はいますが,確率は低いです.
“読者”はこの記事を忘れた頃に読み返す筆者自身を主に想定しています.
この時点ではWifiは使わず有線LANでつないでます.
Manjaro ARMのrootは第2パーティション.
筆者の場合はManjar ARM.
あ,最近した作業のどこかでUUIDで識別しているところもありましたが,どの環境だか忘れました.本筋でないので確認は省略.
システムいじりは一般ユーザとして無責任にsudoを連発して行わず,rootになって責任を自覚しつつ行う.
/usr/lib/systemd/の中身をいじることは推奨されていませんから,/usr/lib/systemd/system/sddm.service/etc/systemd/system/sddm.serviceにコピーしてから改変します.

Raspberry Pi OS Bookwormでfcitx5-mozcのかな入力ができない

かな入力って日常的に使っている人はあまり多くないため,日本語入力ソフトにおける検証が十分なされないことが多々あることをこれまでの経験で知っています.

Manjaro AMD64, 同 ARM64, Debian AMD64ではfcitx5-mozcはちゃんとかな入力可能です.

しかし,先日リリースされたRaspberry Pi OS Bookwormにfcitx5-mozcをインストールした状態ではだめです.少なくとも今のところだめです.どうだめかというと,濁点を打とうとすると, “ふ” になってしまいます.「だくてん」と打ったつもりが,「たふくてん」と表示されます.これでは使い物になりません.

実はManjaro ARM64は日本語のかな入力はfcitx5-mozcでちゃんとできるのですが,FirefoxでWordPressの編集などをしているとよく固まります.そんなわけでRaspberry Pi OS Bookwormが使えるんだったら乗り換えようかと考えていただけに,ちょっと残念です.

その後: 濁点は解決したものの長音記号がNG

いろいろ,いじって濁点は解決しましたが,長音記号が出ません.いじっているのは,CUIのシステムのキーマップ,/etc/X11/xorg.conf.d/内の設定,KDEのキー設定など思いついたキーボード設定に関わるところ手当り次第です.

長音記号についてはシフトを押すと出ますが,基本的にタイピングは文章を考えながらやるので,長音記号のときにいちいちシフトを押すことを気にかけていては文章の作成の思考が止まってしまうので,非常に使いづらいとしか言いようがありません.

ちゃんとかな入力ができているManjaro AMD64のKDE Plasma Desktop + fcitx5-mozcの設定を真似ていますが,どうしたものかDebian ARM64 KDE Plasma Desktop + fcitx5-mozcではうまくいきません.

さらに後の注: 解決

/etc/X11/xorg.conf.d/00-keyboardというファイルを以下の中身のテキストファイルとして作ります

Section "InputClass"
    Identifier "system-keyboard"
    MatchIsKeyboard "on"
    Option "XkbLayout" "jp"
    Option "XkbModel" "jp106"
    Option "XkbOptions" "terminate:ctrl_alt_bksp"
EndSection

ただし,Waylandでは/etc/X11/xorg.conf.d/以下を参照しないようなので意味をなしません.

Raspberry Pi 3 でRTSPを見る(結論)

使い道のないRaspberry Pi 3 Model B (RPi3) やRaspberry Pi 3 Model B+ (RPi3+)で,RTSPを視聴する方法の結論としては,

ffplay (FFMPEG)で見る

で最終決定しました.唯一懸念されていた時間遅れの蓄積は,その後半日ほど連続運転したところ,不思議と解消されました

FFMPEGが使えるならばRaspberry Pi OSでも行けるはずですが,いまさら面倒なので,RPi3ではManjaro ARM xfce, RPi3+ではManjaro ARM KDE Plasmaでこのまま行きます.

自動起動については,

#!/bin/sh
sleep 30
DISPLAY=:0 /usr/bin/ffplay rtsp://ユーザー名:パスワード@ホストのFQDN/指定された文字列 -loglevel quiet -fs > /dev/null 2>&1 &

というスクリプトを実行可能にして適当な場所に置いて設定からAutostartに指定したら,xfceもKDE Plasmaもうまくいきました.sleep 30については要調整です.フルスクリーンオプション-fsはお好みで.

なお,xfceでは設定のScreen saverをOFFが機能しますが,KDE Plasmaはそのスイッチが効かないようなので,ワークアラウンドとして,.xprofile

DISPLAY=:0 xset -dpms
DISPLAY=:0 xset s off

を書いてます.

たぶん,下記のスクリプトのように,コンソールにlogを出さないようにしたためかもしれません.それでも多少は遅れます.
と言いつつ後日試しました.ffplayだけのためにインストールするなら,Raspberry Pi OSが一番楽で,起動も早いのでお勧めです.
一年前にそうだったのですがその後確認はしていません😅

「VLCでrtspを見る」は依然難航中

なんだか相変わらず断片的な書きなぐりなので,何をどうしたくて今どういう問題に直面しているのかというのを一旦まとめます.

最終目標としては,安いモニターカメラが出力するRTSP (Real Time Streaming Protocol)をRaspberry Pi 3 Model B (以下RPi3.Raspberry Pi 3 Model B+はRPi3+)にて視聴するというプロジェクトです.

昨年の段階ではRPi3およびRPi3+にManjaro ARMをインストールして,Manjaroが配布する(もとはArch Linux)VLCで視聴できていました.

しかし,その後一年間モニターカメラの運用を停止していた間にManjaroのVLCもDebianやUbuntu等と同様にRTSPのサポートを止めてしまったようで,RPi3(+)で視聴する方法がなくなってしまいました.

それで現在RPi3(+)でRTSPサポートの付いたVLCを動かす方法を色々探しています.

VLCについて明らかなのは,「本家のVLCはRTSPの視聴が可能」ということです.直接本家がバイナリーを配布しているmacOS版は問題なくモニターカメラからのRTSPを音声込みで再生できています.Windows版については確認していませんが,たぶん同様に問題ないと思います.

一方,Linuxについては,各distroのbuildを尊重しているようです.

SlackwareはdistroにはVLCは含まれていません.SlackBuildsにスクリプトがあるので,sbopkgでbuildできるはずですが,必要なパッケージが35もあってめげてしまいます.それでも気を取り直してまずVLC本体からbuildして,エラーが出るパッケージ(=必須のパッケージ)をbuild & installしていこうと方針を立て,

sbopkg -b vlc

とすると,ソースの配布サイトのアドレスがresolvできないというどうしようもないエラーが出てしまいます.

なお,前述のVLCのダウンロードサイトには,Slackwereのバイナリーのリンクもあります.これはSlackwareに貢献著しいAlienさんがbuildしたもので,試したところ,32bit版も64bit版も問題なくRTSPを再生できます.もし,Alienさんに限らずだれかがARM用もbuildして配布していれば解決なんですが😅

仮想マシンのSlackware 15.0 (32bit版)でRTSPを再生するAlienさんbuildのVLC

ManjaroのVLCもRTSP NGか

色々事情がありまして,しばらくRTSPを視聴せずに来ましたが,また必要にかられて再開しました.

macOSでVLCの本家からdownloadしたVLC media playerは,従来どおり難なく視聴できます.たぶんWindowsでも本家からdownloadすれば使えると思います.

ところが,Manjaro (AMD64版)では視聴できなくなっていました.Debian同様ソースコードにライセンス上の問題があるとかそういう関係でRTSPの機能を除外してしまったのでしょうか

ManjaroでRTSPが視聴可能というのは,Raspberry Piでも視聴可能にできるという大きな意義があったのですが,それができないとなると,Raspberry Piでの監視カメラシステム構築に大きな支障となってしまいます.

さてどうするか

ManjaroのVLCでRTSPの再生ができないことを他のいくつかの環境からテストしてみます.それで確定となれば新しいdistroを探さなければなりません.

Slackwareではsbopkgでbuildできることが解っています.しかし,slackbuilds.orgに登録されているスクリプトは,すべてのアーキテクチャでエラー無くbuildできるとは限りません.特に最終ゴールはRaspberry Pi 3なので,AMD64やx86環境はOKでもaarch64環境でbuildができる可能性は低いと考えています.

それと,依存ファイルの多さです.35もあります.オプショナルなモジュールならば無くてもVLCのbuildスクリプトがその機能を除外して先に進んでくれるようですが,必須のライブラリーがbuildできないとそこでアウトです.一番成功の可能性が高いAMD64でのbuildも躊躇してしまいます.

筆者にはその辺の事情は関係ないので調べません😅
日本の政府やメディアは「防犯カメラ」と呼ばせたいようですが.