テクニカルプア

備忘録と若干の補足

systemd-nspawn を軽くつかって得られたことの記録

docker みたいなことをしたかったが docker よくわからんかったので systemd-nspawn に逃げてみたらいい感じだったので適当につかってみた。
その記録。

systemd-networkd がホストで動いていることが前提(っぽい)

systemd-nspawn は systemd-networkd の機能をガンガンつかっていく。
なので NetworkManager とか netctl とか使っていると痛い目をみる。

ホストからコンテナへの通信

ホストからコンテナへ通信するためには /etc/nsswitch.conf の

hosts: files resolve myhostname

hosts: files mymachines resolve myhostname

にする。これでコンテナのホスト名で名前解決ができる。

ポートフォワード

systemd-nspawn (もしかしたら systemd-networkd の範疇かもしれない)のポートフォワードは結構あてにならない(少なくとも私がやってみたところでは全然うごかなかった)。
web サーバとかを systemd-nspawn でやる場合、ホストでリバースプロキシとかを動かしておいてそこからコンテナにリクエストを転送するようにしたほうがよさそう。

コンテナをおくファイルシステム

ベースになるコンテナをひとつこさえて、いろいろやるコンテナを先のベースコンテナから派生して作りたいとなった場合、

$ machinectl clone <ベースコンテナの名前> <いろいろやる予定のコンテナの名前>

とやって派生したコンテナをつくるが、ここで作られるコンテナは Btrfs の subvolume をつかって作られているので、systemd-nspawn がデフォルトでコンテナを置くディレクトリである /var/lib/machines/ は Btrfs 上に作成されなくてはならない。
そうでないと

Failed transfer image: /var/lib/machines is not a btrfs file system. Operation is not supported on legacy file systems.

とかいわれてコンテナの複製に失敗する。
これを回避する方法として一度

$ sudo machinectl export-tar <ベースコンテナの名前> <適当な名前>

でベースコンテナをエクスポートし、

$ sudo machinectl import-tar <エクスポート先のアーカイブ名> <いろいろやる予定のコンテナの名前>

でイメージをインポートし、ここでいろいろやる、とものがある。ただこの方法はめんどくさいし時間もかかってよくない。

コンテナでは sshd を動かしておいたほうがいい

コンテナ起動後

$ machinectl shell <コンテナのホスト名>

とかでコンテナに入って操作ができるけど、ちまちま操作するのはめんどくさいので Ansible でササッとやってしまいたくなる。
このとき sshd が動いてないと困るので、コンテナをつくるときにあわせて sshd を入れておくのがよい。

(2018-04-01 追記:意地でも Ansible でコンテナをセットアップしたいとかでなければ mkosi をつかったほうが今は良いと思う。mkosi をつかって nspawn 用のコンテナイメージをつくる - テクニカルプア も参照のこと)

Linuxカーネル3.19.3で"kernel BUG at drivers/gpu/drm/drm_crtc.c:536!"とかいわれて困った場合の解決策

 最近になって(記憶が確かでないがLinuxカーネルのバージョンを3.19.3にしてから)、パソコンをシャットダウンしたりリブートしたりすると、画面がブラックアウトし、ウンともスンともいわなくなってしまうという状況がかなりの頻度で発生していた。
 journalctl で確認してみると以下のようなログがあった。

Apr 05 01:04:10 Erika kernel: kernel BUG at drivers/gpu/drm/drm_crtc.c:536!
Apr 05 01:04:10 Erika kernel: invalid opcode: 0000 [#1] PREEMPT SMP 
Apr 05 01:04:10 Erika kernel: Modules linked in: nls_iso8859_1 nls_cp437 vfat fat fuse ctr ccm ipt_REJECT nf_reject_ipv4 mousedev xt_tcpudp nf_conntrack_ipv4 nf_defrag_ipv4 xt_conntrack nf_conntrack iptable_filter ip_tables x_tables tp_smapi(O) thinkpad_ec(O) snd_hda_codec_hdmi ext4 snd_hda_codec_conexant msr snd_hda_codec_generic mbcache iTCO_wdt jbd2 iTCO_vendor_support arc4 iwldvm mac80211 coretemp intel_powerclamp crc32_pclmul btusb bluetooth aesni_intel crc16 aes_x86_64 glue_helper lrw gf128mul ablk_helper cryptd iwlwifi cfg80211 psmouse serio_raw i2c_i801 intel_ips thinkpad_acpi nvram lpc_ich mfd_core hwmon led_class rfkill snd_hda_intel thermal tpm_tis battery snd_hda_controller tpm ac snd_hda_codec snd_hwdep evdev snd_pcm acpi_cpufreq snd_timer snd e1000e mei_me soundcore mei shpchp processor ptp pps_core
Apr 05 01:04:10 Erika kernel:  sch_fq_codel usbip_host usbip_core overlay btrfs xor raid6_pq sd_mod ums_realtek uas usb_storage atkbd libps2 ahci libahci libata xhci_pci crc32c_intel ehci_pci xhci_hcd ehci_hcd scsi_mod usbcore usb_common i8042 serio
Apr 05 01:04:10 Erika kernel: CPU: 3 PID: 1 Comm: systemd Tainted: G           O   3.19.3-1-ck #1
Apr 05 01:04:10 Erika kernel: Hardware name: LENOVO 5397FUJ/5397FUJ, BIOS 6QET70WW (1.40 ) 10/11/2012
Apr 05 01:04:10 Erika kernel: task: ffff880232918000 ti: ffff880232930000 task.ti: ffff880232930000
Apr 05 01:04:10 Erika kernel: RIP: 0010:[<ffffffff812e94bc>]  [<ffffffff812e94bc>] drm_framebuffer_free_bug+0x9/0xb
Apr 05 01:04:10 Erika kernel: RSP: 0018:ffff8802329339c8  EFLAGS: 00010246
Apr 05 01:04:10 Erika kernel: RAX: 0000000000000000 RBX: ffff8802321cd000 RCX: 0000000000000004
Apr 05 01:04:10 Erika kernel: RDX: 0000000000000000 RSI: 0000000000000002 RDI: ffff880072666848
Apr 05 01:04:10 Erika kernel: RBP: ffff8802329339c8 R08: ffff880231110000 R09: 0000000000000004
Apr 05 01:04:10 Erika kernel: R10: 0000000000000002 R11: 0000000000000001 R12: ffff880072666840
Apr 05 01:04:10 Erika kernel: R13: ffff8802321c6000 R14: ffff8802321c6370 R15: ffff8802321ce800
Apr 05 01:04:10 Erika kernel: FS:  00007f565e3cf800(0000) GS:ffff88023bd80000(0000) knlGS:0000000000000000
Apr 05 01:04:10 Erika kernel: CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
Apr 05 01:04:10 Erika kernel: CR2: 00007f565d326e88 CR3: 000000023125a000 CR4: 00000000000007e0
Apr 05 01:04:10 Erika kernel: Stack:
Apr 05 01:04:10 Erika kernel:  ffff8802329339e8 ffffffff812ea7a4 ffff8802321cd000 ffff8800b65b1100
Apr 05 01:04:10 Erika kernel:  ffff880232933a28 ffffffff812dadf7 0000000000000000 ffff8800b65b1100
Apr 05 01:04:10 Erika kernel:  0000000000000000 ffff8802321c6000 ffff880232933c60 ffff8802321ce800
Apr 05 01:04:10 Erika kernel: Call Trace:
Apr 05 01:04:10 Erika kernel:  [<ffffffff812ea7a4>] drm_plane_force_disable+0xb7/0xbc
Apr 05 01:04:10 Erika kernel:  [<ffffffff812dadf7>] restore_fbdev_mode+0x4e/0xd4
Apr 05 01:04:10 Erika kernel:  [<ffffffff812dc7a8>] drm_fb_helper_restore_fbdev_mode_unlocked+0x27/0x5e
Apr 05 01:04:10 Erika kernel:  [<ffffffff812dc815>] drm_fb_helper_set_par+0x36/0x3a
Apr 05 01:04:10 Erika kernel:  [<ffffffff81361f80>] intel_fbdev_set_par+0x1a/0x5d
Apr 05 01:04:10 Erika kernel:  [<ffffffff812db4c4>] ? drm_fb_helper_sysrq+0x23/0x23
Apr 05 01:04:10 Erika kernel:  [<ffffffff81258a56>] fb_set_var+0x2b3/0x3b4
Apr 05 01:04:10 Erika kernel:  [<ffffffff81250387>] fbcon_blank+0x95/0x271
Apr 05 01:04:10 Erika kernel:  [<ffffffff811445a1>] ? cdev_put+0x25/0x25
Apr 05 01:04:10 Erika kernel:  [<ffffffff812afdb3>] do_unblank_screen+0xeb/0x164
Apr 05 01:04:10 Erika kernel:  [<ffffffff812a7e7f>] vt_ioctl+0xc9d/0x11ab
Apr 05 01:04:10 Erika kernel:  [<ffffffff812a3399>] ? n_tty_ioctl_helper+0x123/0x132
Apr 05 01:04:10 Erika kernel:  [<ffffffff8129de66>] tty_ioctl+0xa22/0xaac
Apr 05 01:04:10 Erika kernel:  [<ffffffff8114e046>] ? do_filp_open+0x49/0xad
Apr 05 01:04:10 Erika kernel:  [<ffffffff8115021a>] do_vfs_ioctl+0x375/0x43bi
Apr 05 01:04:10 Erika kernel:  [<ffffffff81158919>] ? __fget+0x70/0x7b
Apr 05 01:04:10 Erika kernel:  [<ffffffff8115033a>] SyS_ioctl+0x5a/0x7f
Apr 05 01:04:10 Erika kernel:  [<ffffffff814a8309>] system_call_fastpath+0x12/0x17
Apr 05 01:04:10 Erika kernel: Code: bb b8 02 00 00 e8 2b 82 f1 ff 4c 89 ef e8 48 cf 1b 00 4c 89 e7 e8 2b 4f e4 ff 5a 5b 41 5c 41 5d 5d c3 66 66 66 66 90 55 48 89 e5 <0f> 0b 66 66 66 66 90 55 48 89 e5 53 48 89 fb 50 e8 58 e8 ff ff 
Apr 05 01:04:10 Erika kernel: RIP  [<ffffffff812e94bc>] drm_framebuffer_free_bug+0x9/0xb

 適当に調べていると Re: Kernel panic every other reboot/poweroff since 3.19.3 ( commit 9a6f5130143 ) -- Linux Intel GFX というページが見つかった。
これは Re: Kernel panic every other reboot/poweroff since 3.19.3 ( commit 9a6f5130143 ) -- Linux Intel GFX で報告されている前述と同様の問題に対する解決策を案内するもので、それは ~airlied/linux - Official DRM kernel tree にあるパッチを drivers/gpu/drm/drm_crtc.c へあてるというものになる。

 とりあえず当該パッチを当てたカーネルコンパイルが今終わったところなのでこれからインストールして再起動させ様子をみることにする(再起動後追記:いい感じになった)。
 いろいろやるのが面倒な場合は3.19.4の公開を待つと多分解決する。あるいはArch Linuxが配信するバイナリパッケージのカーネルをしばらく使うというのでもよい。2015年04月05日現在Arch Linuxのバイナリパッケージで提供されるLinuxカーネルは3.19.2であり、上記の問題が発生することは(少なくとも私の環境では今までに)なかった。

pacman 4.2で吐かれるpacaur関連のエラーへの対処法

 pacmanのバージョンが4.2になったが、この状態でpacaurを使うと

cower: error while loading shared libraries: libalpm.so.8: cannot open shared object file: No such file or directory

とか

expac: error while loading shared libraries: libalpm.so.8: cannot open shared object file: No such file or directory

というエラーが出て、AURのパッケージに関する操作が出来なくなる。
 pacman 4.2に際してpacmanのライブラリ(libalpm)が更新された為、あたらしいlibalpmを使ってcowerもexpacもコンパイルされないといけない様子。
 というわけなので、AUR (en) - pacaurAUR (en) - cowerで触れられているように、pacmanのバージョンを4.2に上げた状態でcowerを再ビルドしてインストールする必要がある。
expacについてもエラーが出る場合も同じくpacmanのバージョンを上げて再ビルドすればよい。cowerとは異なりexpacはextraレポジトリにあるArch公式のパッケージなので、こういうとことかからパッケージ作るのに必要なやつを持ってくる必要がある。

KMSのearly modeでブート時にTuxを鎮座させる

(2015-03-05 追記:以下に示す方法であっても、特に私自身の環境ではTuxが出てこなくなってしまった。原因はいまだわからない)

 Linuxカーネルコンパイルを知って以来、ずっとブートシーケンス中にTuxを鎮座させる事を夢見ていた。Arch Linuxが配布するカーネルではブートロゴが表示される設定になっていないので、Tuxは鎮座しない。
f:id:aaodsn:20141128225921j:plain
 基本的には Gentoo Forums :: View topic - Tux at top of screen during boot? に従えばいいんだけど、KMSを利用する環境でearly modeになっている場合*1カーネルパラメータをいじくる手間がいらなくなるかわりにもう一手間増えて、グラフィックスに関するドライバをビルトインにしないといけなくなる。つまり、Intel製のグラフィックスの場合、

CONFIG_DRM_I915=y
CONFIG_DRM_I915_KMS=y
CONFIG_DRM_I915_FBDEV=y

という設定にしなければならない。上のリンクに沿って言えば、

Device Drivers --> Graphics support --> Direct Rendering Manager --> Intel 8xx/9xx/G3x/G4x/HD Graphics

の箇所をモジュール("M")ではなくビルトイン("*")にする必要がある。

理屈

 正しい理解をしている確証もなく、一次資料に目を通したわけでもないので参考情報として解釈してほしい。

KMSとは

 kernel mode settingの頭字語。Linuxカーネルからグラフィックスあたりを操作する為の仕組み。

initramfsとKMS
  • Arch Linuxでmkinitcpioはinitramfs(カーネルイメージとかいわれる)を生成するためのスクリプト
  • mkinitcpioは /etc/mkinitcpio.conf の内容を読み込む
  • KMSがearly modeになっている場合、KMSに必要なモジュールはシステム起動時の早い段階でカーネルに読み込まれる
  • 早い段階でモジュールが読み込まれるとはいうものの、その際あるいはその前にドライバが読み込まれるとは限らない
    • 実際、ドライバをビルトインにしなかった時はTux鎮座しなかった
  • カーネルにグラフィックスのドライバを組み込んでおけばモジュール読み込み後すぐグラフィックスが利用できる

おまけ

 /proc/config.gz をzcatしたやつを晒す。AUR (en) - linux-ckThinkPad X201sで利用することを前提としている。4000行くらいあって、ページを無駄に重くするだけだと思われるので、晒すとは書いたがリンクを貼るにとどめておくことにする:zcat /proc/config.gz
 configの行数がかさむのは修行が足らない証だ。

*1:/etc/mkinitcpio 内の"MODULES"にグラフィック関連のモジュールを加えている場合が該当する。MODULES=i915 みたいな記述があるなど。

MeCabをpython3で使うためのパッチ書いた

 CaboChaをpython3で使うためのパッチ書いた - テクニカルプアの続きっぽい感じ。

 パッチは以下の通り。CaboChaの場合と変更点に違いはない。

 以下個人用メモ。自然言語処理をやってる人にしてみれば常識なんだろうけど私は自然言語処理をやっていないので。

  • MeCabMeCab用辞書があって初めて動く
    • 辞書が無いとRuntimeErrorとか言われる
  • CaboChaはMeCabがきちんと動く事ではじめてちゃんと動作する
    • MeCabがグズってるとpython周辺を飛び越えてC++辺りのコードからエラーが飛んでくる

ThinkPad X201s買った

f:id:aaodsn:20141007214600j:plain

 物欲が爆発して頭が真っ白になり、気がついたら注文を完了していた。送料込54000円也。型番は5397-FUJ。
 程度の良いX201(s)が2万円代で手に入る未来をずっと待っていたけれど、ThinkPadの凋落が悲鳴に近い形で叫ばれ始めたときにそんな未来は来ないだろうと見通しを立てるべきだったと思った。
 これで当分物欲に苦しめられることはなくなるだろう。

Qtでの動作を念頭に置いて設定等をしたFcitxがGTK+なアプリ上で動かなくて困った時に確認すると嬉しいかもしれない事項一覧

 いろいろあってTox*1シンパになった。
 しかし困ったことに、慣れ親しんだuimはToxのQtフロントエンドであるqTox*2で必要となるQt5に公式には対応しておらず、結果日本語が使用できない。
 githubにあるuimのレポジトリなどから入手できる最新の不安定版では一応Qt5に対応しているようだが*3、それを使うとqToxがSegmentation Faultという断末魔を上げて死んでしまう*4。日本語話者なのでToxでも日本語を使いたくて困っていたけれど、これまたいろいろあってuimをやめてQt5に対応済みのFcitxに移行すれば良いのだと気がついた。
 ここでタイトルの登場となる。つまりはそうなったのだ。

前提

Qtでの動作を念頭に置いて

というのはつまりFcitxを導入するときに以下のようにインストールした場合という意味:

$ sudo pacman -S fcitx-im fcitx-im-qt5 kcm-fcitx kdeplasma-addons-applets-kimpanel

その他Fcitxのインストールや設定に関する情報は全てFcitx (日本語) - ArchWikiを参照した。

確認事項

プロファイル系の設定ファイル

 .xprofileとか.xinitrcとかを意味する。ここに追記するFcitxに関しての内容が

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

となっているかをみる。以上の内容で駄目な場合は一行加わって

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

となることもある。

ロケール

 LC_CTYPEが"ja_JP.UTF-8"ではない場合、GTK+なアプリでIMEが有効にならない場合がある。
 ArchWikiによれば(GTK+アプリではないものの)これはEmacsのバグでEmacs上で生じるみたいなことが書いてあった。だがGTK+を使用しているはずのChromiumやmikutter上でもIMEが有効にならないことがあった。
 これについては/etc/locale.confや${HOME}/.xinitrcなどの適当な設定ファイルへ

export LC_CTYPE="ja_JP.UTF-8"

と書けばよい。

GTK IM Module

 GTK+のIM関連の設定を更新するといい感じになることがある。これは以下のようにする。

# gtk-query-immodules-{x}.0 --update-cache

{x}は2か3で置き換えるGTK+ 2系を対象にする場合は"2"で、GTK+ 3系を対象にする場合は"3"でそれぞれ置き換えて実行する。
 詳細はFcitx (日本語) - ArchWikiを参照。

GTK+の外観設定ファイル

 .gtkrc-2.0や.gtkrc-2.0-kde4のようなファイルがホームディレクトリ直下に存在する場合、これをリネームするか削除するかすると良い感じになる事がある。GTK+ - ArchWikiによれば、これらのファイルはGTK+アプリで外観周りの設定を記述するための設定ファイルであるようだ。

*1:https://tox.im/

*2:https://wiki.tox.im/QTox

*3:こういうのがAURにもある:AUR (en) - uim-qt5

*4:qToxの問題かと思ったけれど、fcitxでもvi-cooperative modeもどき | とさいぬの隠し部屋によればQt5のアプリであればqToxに関わらず全部死ぬようだ