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です．
