Manjaroの弱点

筆者の愛用しているManjaroはrolling release modelというバージョンアップの方法を採用しています(ベースのArch Linuxがそうであるため).

まあ,GentooSlackware-currentも同様ではあります.この手のdistroの弱点は,しばらくupdateをしないで放置しておくと通常のupdateの手段ではupdateができなくなってしまうことです.

実マシンから作ったディスク仮想イメージとして存在させている仮想マシンは,もとの実マシンのバックアップ的な意味合いなので存在感が薄く,気がつくと最後の更新が何か月も前だったりします.

筆者のLinux第一WSであるManjaro AMD64も,ときどきバックアップのためにディスクを仮想化して仮想マシンに仕立ててます.仮想マシンとしても実は一番気に入っているので,Mac mini2台と実マシンであるManjaroのWS自身の中で仮想マシンとして “飼って” います.

気に入っているとは言えバックアップなので新し味がなく,ときどきupdateが何か月ぶりになってしまうことがあります.そんなときは他のupdate可能なイメージをコピーしたり,新たに実マシンから仮想化しました.パックアップの更新としての意義があります.

たまたま,前日updateができなくなった状態をあるSNSに投稿したら,親切な方が,

pacman-key --refresh-keys
pacman -Sc

を試してみてはと教えてくださいました

一台目はそれで復活しました.しかし,別の仮想マシンが同様の症状になっていましたが,上記の方法では復活できませんでした.1勝1敗です.

NGなほうはさらに別のマシンで動いているupdate可能なManjaroのディスクイメージをコピーして差し替え,動くようになりましたが,バックアップの意味を込めて後で久しぶりに実マシンから仮想化しようと思います.

筆者はシステムのメンテはrootでログインした状態で行うことをポリシーにしています(Slackware流)ので,コマンドごとにsudoを使う事はしません.

バックアップの削除でサーバーが無応答に

現在サーバーのバックアップは,バックアップの際にマウントする2TBのHDDに,前回からの差分をバックアップする形にしています.

rsyncでバックアップしています.今日の日付からなるディレクトリーをバックアップのボリュームに作り,ひとつ前の日付のディレクトリーを--link-destオプションで指定してサーバー内の全部(ただし,バックアップのボリュームのマウントボインや/tmp, /dev等は除く)をコピーすることで,変更がないファイルはハードリンク,変更があったファイルは新しいファイルをコピーするようなことを勝手にやってくれます.

rsyncは優秀で他のサービスに影響ありません.だいたい15分くらいで終わります.ただし,毎日毎日バックアップを続けると,だんだんハードリンクが長くなるせいか,バックアップに要する時間が長くなってきます.30分,1時間,ついには1時間越えと.

そこでときどき古いバックアップを削除します.手作業です.削除は普通にrmコマンドに-rオプションを付ければよいです.ただこれがなかなか重い作業で,rm自体はメモリーをほとんど食わず,SWAP領域が増えることもないのですが,kswapd0デーモンがかなりCPUサイクルを食います.何が起こっているかよく解らないのですが,ルートドライブもこのバックアップドライブもUSB接続だというのが良くないのではないかと今は推測しています.

昨日もずっとhttpdやその他のデーモンが動かなくなっていたのを知っていましたが,rmコマンドを途中でやめるわけにも行かず,一晩そのままにしておきました.

rmコマンドが終了しても,デーモン類はスタックしたまま自動的には復活しないので今朝システムごとリブートしました.

今後はバックアップの削除は他のWSにつないで行うことにします.

ATOK Passport 再契約

去年の7月にATOK Passportを解約して,無料で使える日本語入力ソフトのうち一番まともそうなGoogle日本語入力を使ってきました.Google日本語入力はMozcとも共通部分があるから,使い勝手がLinuxのいくつかのWSと通じるという利点も期待しました.

それから1年3か月ですがもう限界なので再びATOK Passportの契約をしました.

何が悪いかというと,連文節変換がバカすぎです.なかなか実例が思い出せませんが,連文節の変換で前後何の関連性もない変換をします.これが一番の理由ですが,ATOK Passportで複数のクライアント間のユーザー辞書のシンクロも,失ってみるとかなり大きな存在であったと感じます.

あと,多少の誤入力を自動的に修正してくれるのも,やはり失うとその機能のありがたさを感じます.

だいたいそのくらいでしょうか.もちろん,Google日本語入力でも,手動でユーザー辞書の同期(具体的にはユーザー辞書を書き出してクラウドにおいて他のマシンでダウンロードして辞書ツールでマージする)はできますが,これを自動的に毎日やってくれるのはそれだけでも価値があります.

今回もベーシックプランとしました.今後試しにプレミアムにしてみる可能性は排除しないことにします.

Workstation.
これは当初から解っていたことでもありますが.

バックアップから仮想マシン作成 (Debian)

長年こんなことをやってます.ただし,年がら年中でなく,時々思い出したようにやるのでたいてい前のことは覚えていません.

そんなわけで自分用のメモです.

前提条件

稼働している実マシンないし仮想マシンから,定期的にrsyncにて差分もしくは完全バックアップを取っている.

まあ,完全と言っても,/dev, /tmp, /proc, /sysはたいてい外していると思います.

また,バックアップ元のマシンはSWAPはzramのみでSWAPパーティションはなく,ルートパーティションも一本でマウントするボリュームはなしです.

仮想ディスクの作成

仮想ディスクは,qemu-imgで作ります.形式はQEMU/KVMならばqcow2,VMWareならばvmdkでしょう.もちろんraw形式や他の形式でも大丈夫ですが,最終的に収まる仮想マシンのデフォルトにしておくのが無難でしょう.

qemu-img create -f qcow2 ファイル名.qcow2 40G

次にパーティションを切ります.nbdの出番です.以下はroot権限での作業になります.

modprobe nbd
qemu-nbd --connect /dev/nbd0 ファイル名.qcow2
fdisk /dev/nbd0

パーティション形式はGPTにします.EFI用のパーティション512MBを “BIOS boot” 形式にして,残りをLinux filesystemにします.

そして,mkfsでフォーマットします.

mkfs -t ext4 -j /dev/nbd0p2
mkfs -t vfat /dev/nbd0p1

引き続き,/dev/nbd0p2を/mnt/hdなどにマウントして,

rsync -artlvd --numeric-ids バックアップのディレクトリー /mnt/hd

バックアップしてない必要なディレクトリーを作ります.

cd /mnt/hd
mkdir dev tmp sys proc
chmod -v a+rwx tmp
cd
umount /mnt/hd
qemu-nbd --disconnect /dev/nbd0
rmmod nbd

仮想ディスクをブータブルに (GPT)

仮想ディスクを仮想マシンのホストで一つの仮想マシンのディスクとして登録します.次に,バックアップしたDebianと同じバージョンのインストーラーをダウンロードして,その仮想マシンのDVD/CDとして登録し,起動ディスクに指定します.

あとは,Advanced > Rescueとして,メニューに従って進めば,仕立てた仮想ディスクをルートにマウントしてくれるので,

dpkg-reconfigure grub-pc

とすれば,ブータブルになりますので,DVD/CDを外してディスクから起動させます.何かエラーが出たら修正します.

仮想ディスクをブータブルに(MBR)

仮想ディスクをGPTでなくてMBRでパーティションを切ってしまった場合,上記の方法ではうまく行かないかもしれません.この場合,筆者の標準的なパーティションはルートだけの一つになっています.

grub-install /dev/sda
grub-mkconfig -o /boot/grub/grub.cfg

で,うまく行くと思います.

起こりがちなエラー

エラーとしてありがちなのは,/etc/fstabに記したルートドライブの情報が仮想マシンの仮想ディスクとマッチしないことです.その場合は,もう一度レスキューモードにして,/etc/fstabを修正したうえで,dpkg-reconfigure grub-pcをやり直します.

ネットなどについては起動してから修正できます.

案外簡単です.

不定期的でも問題ないですが.

LIRC再び (2)

自分の記事を元にLIRCに再挑戦のつもりが,あまりに設定などに違いがあるので,他所様の記事を参考に設定完了までこぎつけました.

しかし,その先がいかんです.参考にした記事はsystemdではない😅

まあでも,そこだけ気をつければ行けそうです.

systemctl status lircd
sudo systemctl stop   lircd
mode2 -d /dev/lirc1

で,なんかそれらしいものを受信するようになりました.

次は目的のリモコンのコードの解析です.