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にコピーしてから改変します.

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も躊躇してしまいます.

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

仮想マシンと実マシンの行き来についてまとめ update 2

前項「仮想マシンと実マシンの行き来についてまとめ update」に関して,その後新しいことがわかったのでupdateします.

実マシンから仮想マシンへの移行

これは比較的楽です.Linux distroの32 bit版でも64 bit版でもたいていうまくいきます.仮想マシンの仮想ディスクイメージ(以下「仮想イメージ」と略します)は,MBRでもGPTパーティションでも大丈夫です.仮想マシンでマルチブートする必要はありませんし,SWAPにzramを使用すれば,MBRではroot用の1本のパーティションで済みます

ブートローダーの設定は,Slackware64 15.0のインストール用DVDイメージからブートさせて,chrootして設定します.もちろん他のdistroのインストールDVDイメージでもできますが,使い慣れていることもあり一番堅実な感じがします.

32bit OSについては同様にSlackwareのオリジナル(32bit版)を使用します.

これで,Slackware 32/64, Debian 32/64, Manjaro 64のそれぞれの実マシンを仮想化できています.

特に他の設定で引っかかるところもありません.fstabの記述は最初は/dev/sda1などにしておいて,必要に応じてUUIDなどに書き換えれば良いと思います.

十分習熟したこともありますがほぼまちがいなく仮想化できます.

仮想マシンから実マシンへの移行

こちらは,難易度が少し高いです.基本的には第1OSのManjaroのGRUBから起動するようにします(ただし,grub.cfgの手直しが必要).

64bit版 Linux

64bit版については,第1OSであるManjaroのGRUBから,Debian, Slackware64, Manjaroをブートできるようにできました.

設定の要所としては,第1OSのManjaroのgrub.cfgの手直しと,コピーした第2OSのfstabの記述をUUIDにしておくくらいでしょうか.

唯一Debian AMD64については,第1OSのManjaroのEFI+GRUBからのブートに加えて,自前のEFI+GRUBからのブートもできるようになりました.しかし,過去にはうまく行かなかったこともあり,どうするとうまく行ってどうすると失敗するのかは解っていません.

32bit版 Linux

32bit版に関しては,基本的に64bit版と同じ手順・注意で実マシンの移行自体はできています.しかし,引越し先のハードとのインコンパチが原因と思われるトラブルにつきまとわれています.

Slackware 15.0 の32bit 版は,第1OS ManjaroのGRUBから起動はしますが,何回かに1度ブートに失敗して,BIOSのブート画面に戻りますが,再度ブートすればたいていsddmが表示され,KDEにログインできます.

Debian 32bit paeについては,CUIは起動しますが,GUIではXは起動しますが,sddmが起動してくれません.いや,起動はしているのですが画面が全面黒でポインティングディバイスに連れてポインターは動き,場所に応じてIビームや矢印になります.試しにパスワードを入力してみると,ログインできたようですが,KDEのデスクトップは表示されず黒画面のままです.

これは,ビデオドライバーのインコンパチに違いないと当たりをつけ,Xorg.0.logを見ると,glamoreglというドライバーが選択されています.ビデオカードは “NVidia GeForce GT 640” という古いものです.たぶん,64bitでは問題ないのでしょうが今更32bit版を使う人も少ないので32bit版ではバグが潰しきれていないのではないでしょう.

/etc/X11/xorg.conf.d/内に,01-video-driver.confというテキストファイルを作りました.内容は,

Section "Device"
     Identifier "Card1"
     # Driver "nouveau"
     Driver "fbdev"
     BusID "PCI:1:0:0"
EndSection

です.そう,最初に “nouveau” を試しましたが,sddmは表示されログインできますが,KDEのデスクトップが表示されたところで画面はフリーズしてしまうので, “fbdev” にしたところ,いろいろDesktop Effectsは使えませんが,とりあえずはKDEが使えるようになりました

仮想マシンの実マシン化に直接は関係ありませんが,付随した問題なので記録しておく次第です.

“distribution” の略は “distro” です.「ディストリ」と略して書くと,英語のドキュメントを読んでないことがバレます.
GPTの場合はBIOS BOOTパーティションが必要.
特に電源投入後初回のブート時はほぼ100%失敗します.
Debian 9時代まで実マシンだった.
この記事も,Debian 32bit pae bookwormのKDEで動くFirefoxから書いてます.

仮想マシンと実マシンの行き来についてまとめ update

前項「仮想マシンと実マシンの行き来についてまとめ」に多少勘違いなどがあったので,updateします.

実マシンから仮想マシンへの移行

これは比較的楽です.Linux distroの32 bit版でも64 bit版でもたいていうまくいきます.仮想マシンの仮想ディスクイメージ(以下「仮想イメージ」と略します)は,MBRでもGPTパーティションでも大丈夫です.仮想マシンでマルチブートする必要はありませんし,SWAPにzramを使用すれば,MBRではroot用の1本のパーティションで済みます

ブートローダーの設定は,Slackware64 15.0のインストール用DVDイメージからブートさせて,chrootして設定します.もちろん32bit OSについてはSlackwareのオリジナル(32bit版)を使用します.これで,Slackware 32/64, Debian 32/64, Manjaro 64のそれぞれの実マシンを仮想化できています.

特に他の設定で引っかかるところもありません.fstabの記述は最初は/dev/sda1などにしておいて,必要に応じてUUIDなどに書き換えれば良いと思います.

十分習熟したこともありますがほぼまちがいなく仮想化できます.

仮想マシンから実マシンへの移行

こちらは,難易度が少し高いです.基本的には第1OSのManjaroのGRUBから起動するようにします(ただし,grub.cfgの手直しが必要).

32bit版 Linux

32bit版に関しては,実マシンの移行自体はできたもののトラブルにつきまとわれています.

Debian 32bit paeについては,CUIは起動しますが,GUIではsddmが起動してくれない,というところまでは行きます.本体のKDEにログインできませんが,その他の機能は問題ないようで,他のマシンからsshでつないで調べてみたりしていますが,今のところ解決していません.

また,Slackware 15.0 の32bit 版についても,第1OS ManjaroのGRUBから起動はしますが,何回かに1度ブートに失敗して,BIOSのブート画面に戻りますが,再度ブートすればたいていsddmが表示され,KDEにログインできます.

64bit版 Linux

64bit版については,第1OSであるManjaroのGRUBから,Debian, Slackware64, Manjaroをブートできるようにできました.

設定の要所としては,第1OSのManjaroのgrub.cfgの手直しと,コピーした第2OSのfstabの記述をUUIDにしておくくらいでしょうか.

唯一Debian AMD64については,第1OSのManjaroのEFI+GRUBからのブートに加えて,自前のEFI+GRUBからのブートもできるようになりました.しかし,過去にはうまく行かなかったこともあり,どうするとうまく行ってどうすると失敗するのかは解っていません.

GPTの場合はBIOS BOOTパーティションが必要.
Debian 9時代まで実マシンだった.
特に電源投入後初回のブート時はほぼ100%失敗します.

仮想マシンと実マシンの行き来についてまとめ

まとめというより,まだ途中経過ではあります.

実マシンから仮想マシンへの移行

これは比較的楽です.Linux distroの32 bit版でも64 bit版でもたいていうまくいきます.仮想マシンの仮想ディスクイメージ(以下「仮想イメージ」と略します)は,MBRでもGPTパーティションでも大丈夫です.仮想マシンでマルチブートする必要はありませんから,MBRにしておけばBIOS BOOT用パーティションなしの1本のパーティションで済みます.

ブートローダーの設定は,Slackware64 15.0のインストール用DVDイメージからブートさせて,chrootして設定します.もちろん32bit OSについてはSlackwareのオリジナル(32bit版)を使用します.これで,Slackware 32/64, Debian 32/64, Manjaro 64のそれぞれの実マシンを仮想化できています

十分習熟したこともありますがまずまちがいなく仮想化できます.

仮想マシンから実マシンへの移行

こちらは,難易度が高いです.特に32bit版についてはまぐれで1度Slackware 15.0を第1OSのManjaro AMD64版のGRUBからブートできるようになりましたが,その後は再現できていません😅

Debian 32bit paeについては,CUIは起動しますが,GUIではsddmが起動してくれない,というところまでは行きます.

64bit版については,ManjaroのGRUBからDebian, Slackware64, Manjaroを第1OSであるManjaroのGRUBからブートできるようにはできました(ただし,grub.cfgの手直しが必要).

また,唯一Debian AMD64については,第1OSのManjaroのEFI+GRUBからのブートに加えて,自分のEFI+GRUBからのブートもできるようになりました.しかし,過去にはうまく行かなかったこともあり,どうするとうまく行ってどうすると失敗するのかは解っていません.

とはいえ,「仮想マシンから実マシンへの移行」で,32bit版はほとんどうまく行っていないと記しているとおり,最近は32bit版の実マシンが存在していませんから,その仮想化のテストはできていません.
Debian 9時代まで実マシンだった.