テクニカルプア

備忘録と若干の補足

松花堂弁当と妄想

浜松の友人が ThinkPad について懐古していたので、こちらも懐古してみようと思った。これに加えて最近ずっと考えていることも文章にしてみるつもり。

現在に至ってもまだ手元では X201s がメインのマシンである。X220 に移ろうかなと思うこともあったが、これはどちらかというと X220 を使いたいという気持ちではなく物欲の発散に近いものがあると自分でもわかっていたので押さえ込んでいた。
おそらく今の X201s が私の最後の ThinkPad になるような気がしている。X201s が修理不可能な状態まで崩壊してしまうか物欲が臨界点を超えて爆発したら MacBook Pro あたりを新品で買うのだろうなと思う。ThinkPad 生活も中古 PC 生活も終焉である。

ThinkPad を使い始めたのは X40 が最初だった。その後部品を買い集めて X41 を組み、気の迷いで X32 を買って放置し、スペック不足に悩んで X61 を買い、なんかよくわからん間に X60 やら X61s が手元に湧いてきたりした。B5 ノートしか使うつもりはないみたいな事をいいながら T61 を買ってつかってみたら便利で手放せなくなったというようなこともあった。その後 X200 を買い、ThinkPad の終焉を悲しんで X201s を買い、今に至る*1
X40 や X41 は薄くて軽くて使いやすい素敵なマシンだった。ただし性能不足は如何ともしがたく、あれこれシステムボードを買い換えたりディスクを ZIF -> IDE 化したり SSD 化したりいろいろし、バラバラに分解ということも何回もやった。このころ普段つかう OS を Windows から GNU/Linux にかえた。
X61 になってから突然筐体が分厚くなりパームレストが熱くなった。事前情報として知っていたのでうろたえはしなかったし、スペック向上のトレードオフなのだろうなと考えている。X60X61、X61s についてもシステムボード交換を含め何度もバラバラに分解し、手垢がつくほど様々なところをいじくりまわした。いちばん中身をいじくり回したマシンは X61 だと思う。
X200 や X201s にしてから横幅が広がり、画面の解像度が高くなった。横幅が広がったのは当初戸惑ったが慣れるに従い X61 の画面が狭く感じるようになったことが印象深い。 この世代になってから中身をあまりいじらなくなった。
X32 や T61 は忘れた。

いま手元に残っているのは X41、X61、X201s のみ。
中古 PC 屋やジャンク屋、ヤフオク等を漁ることもしなくなり、以前は暇さえあれば行っていた意味のない分解もしなくなった。
ThinkPad の終焉に伴い、次はなにを買おうか、次はどの部品を替えようかという気持ちもなくなった。単に老化かもしれないが。

ローカル PC のスペックは少なくとも個人用途に限ればクラウドなりなんなりでどうとでもなる昨今の事情をみるに、「いかに高性能なマシンを入手するか」ではなく「いかに使いやすい道具を仕入れるか」「いかに手に馴染む道具を手に入れるか」という方向で PC を選んだほうがいいとずっと考えている。
この「使いやすい道具」「手に馴染む道具」がいままでずっと ThinkPad だったわけだが、未来の*2 ThinkPad

という理由でどうしても使いやすい或いは手に馴染む道具であるとは思えず、他の機種へ鞍替えが必要になってしまった。
逆に言えば既に今使いやすい道具が手元にあり、それが崩壊せず完動するならばその使いやすい道具を維持管理すれば良いわけで、未来の ThinkPad に絶望するよりはいま動いている X201s をお世話するほうが有意義である。

古くて使いやすいものをずっと使い続けられる昨今の状況を嬉しく思う反面、死屍累々の未来を眺めるのがとても悲しい。

*1:以上全部中古およびジャンク品

*2:中古目線での「未来」であることに注意

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の凋落が悲鳴に近い形で叫ばれ始めたときにそんな未来は来ないだろうと見通しを立てるべきだったと思った。
 これで当分物欲に苦しめられることはなくなるだろう。