自分の記事を元にLIRCに再挑戦のつもりが，あまりに設定などに違いがあるので，他所様の記事を参考に設定完了までこぎつけました．
しかし，その先がいかんです．参考にした記事はsystemdではない😅
まあでも，そこだけ気をつければ行けそうです．
systemctl status lircd
sudo systemctl stop lircd
mode2 -d /dev/lirc1で，なんかそれらしいものを受信するようになりました．
次は目的のリモコンのコードの解析です．
Category: systemd
Manjaro AMD64 ぶっ壊す
Workstation (WS)をぶっ壊すのは日常茶飯事ですが，これまであまり壊すことのなかったManjaro AMD64 (x86_64)をぶっ壊しました．
先日Manjaro AMD64がKDE Plasma Desktop 6にupgradeされて喜んだのですが，どうもzramがぶっ壊れているのに気が付きました．
色々調べて，systemd-swapが機能していないことがわかりました．systemctl statusで見ると，sysv_ipcがインポートできないことがわかりました．
更に調べると，このsystemd-swapはout-of-dateとなっていることがわかりました😥
それで，Archlinuxのzramのドキュメントを読みながら色々やっていたのですが，どれをやってもうまく行かず，挙句にはEFIをぶっ壊して起動しなくなってしまいました．
EFIがぶっ壊れてはサブWSであるSlackware64もブートできず，にっちもさっちも行かない状況に陥りました．
まずは，Slackware64のブート用USBメモリーから起動して，Slackware64のEFIとGRUBを直して起動するようになりました．ここまでは大した手間ではありませんでした．
このあと，Manjaroのパーティションに4月のバックアップをrsyncでコピーしましまたがうまくブートしません．libvirdがどうのこうのいう，本質的には関係ないエラーなんですが，そのエラーの先に進んでくれません．念の為，Manjaroのパーティションをformatしてからrsyncしましたが，同じ結果でした．
しかたないので，libvirtdを起動しないようにしてある仮想マシンのイメージからrsyncをかけたら，ようやくブートしました．
どうも，rsyncで差分をバックアップしたものからの復元はこのManjaro AMD64に限ってはうまくいかないようです．もちろんあるサブディレクトリー以下とか，特定のファイルについては簡単に復元できるのでバックアップを取る意義はありますが，まるまる起動可能なバックアップとして今までより頻繁に仮想マシンの仮想ディスクにクローニングすることにします．
まともに動くところまでロールバックしたところで，systemd-swapを消して，もう一度，Archlinuxのzramのドキュメントを読みながらやり直します．
udevルールによる方法
結局うまく行ったのは，Archlinuxのドキュメントのうち，udevルールを使う方法です．手順としては，
- これまで使っていたZramのサービスが起動しないようにする
/lib/mdoules-load.d/zram.confに，zramの一行のみ書く/lib/modprobe.d/zram.confに，options zram num_devices=8の一行のみ書く- /etc/udev/rules.d/99-zram.rules に，
KERNEL=="zram[0-7]", SUBSYSTEM=="block", DRIVER=="", ACTION=="add", ATTR{comp_algorithm}="lz4", ATTR{disksize}="1024M", RUN+="/sbin/mkswap $env{DEVNAME}"
の一行のみを書く - /etc/fstabに，
/dev/zram0 none swap defaults,pri=100 0 0
/dev/zram1 none swap defaults,pri=100 0 0
/dev/zram2 none swap defaults,pri=100 0 0
/dev/zram3 none swap defaults,pri=100 0 0
/dev/zram4 none swap defaults,pri=100 0 0
/dev/zram5 none swap defaults,pri=100 0 0
/dev/zram6 none swap defaults,pri=100 0 0
/dev/zram7 none swap defaults,pri=100 0 0
を書く - 祈りながらリブート
だったと思います😥
1のあとの再起動で，zramモジュールがロードされていないことを確認，3の後の再起動でzramモジュールがロードされ，4のあとの再起動で/dev/zram0〜7ができていることをそれぞれ確認，など途中要所要所で動作確認をすると着実に進められます．
以上，未来の自分あてのメモでした．
厳密には，メインWSはMac miniで，Manjaro AMD64がサブWS，Slackware64の実マシンはサブサブWS，またはサブWSのサブOSです．
かんたんに書いてありますが，rsyncののち，chrootして，efibootmgrやgrubのツールを使って起動するように呪いをかけます．
Slackware ARMとRaspberry Pi OS 64bitのMariaDBはバイナリーコンパチ
標記の件確認しました．そうだろうとは思っていました．逆にそうでなかったなら何なんだろうとも思っていました😥
これで，Raspberry Pi 5導入時にサーバーのOSをRaspberry Pi OS 64bitにする最大の懸念が払拭されました．
一応確認した方法を書いときます．
Slackware ARMのMariaDBを，
/etc/rc.d/rc.mysqld stopで停止させてから，/var/lib/mysql以下をtarで固めてsftpするか，rsyncを使ってRaspberry Pi OS 64bitのマシンの適当な作業ディレクトリーに置いときます．
以下はRaspberry Pi OS 64bit側での作業です．
apt install mariadb-serverで，mariadbのサーバーをインストールします．これだけでMariaDBが動き出しますが，念の為動作を確認してからおまじないを実行します．
systemctl status mariadb
mysql_secure_installationこれで，rootだけログインできる空のデータベースが動き出します．ここで一旦，
systemctl stop mariadbで，MariaDBを停止させて，
cd /var/lib
mv mysql mysql-emptyあとは，Slackware ARMから持ってきたデータを展開してから，/var/lib/mysqlとして置きます．念の為，/var/lib/mysql以下のオーナー・グループがmysql:mysqlになっているか確認してなってなければ修正します．
これで，
systemctl start mariadbとして起動を確認して，あとはSlackware ARMで使っていたユーザーでログインして中身を確認します．
コマンドラインだけでは不便なので，phpMyAdminをあとでインストールしたいと思います．
Slackware ARMのMariaDBは再起動しておきます．
一時的にWebサーバー止まります
Manjaro ARMのAvahi解決 おまけ
firewalldを動かして，Avahi (mdns)を機能させる方法については，ネット検索するとすぐ見つかったので，firewalldを動かしたままにすることにします．
- avahi をセットアップする (Meaningless Notebook)
上記ページからの引用:
firewall-cmd --add-service=mdns --permanent firewall-cmd --reload
元記事は，CentOSのケースですが，Manjaro ARMでも同じでいけました．BLOG主さん，ありがとうございます．