cheep, cheep, cheep...

_ Ubuntu で nvidia docker が動かないトラブル

TLDR

docker-ce をインストールするなら， snap の docker パッケージも purge すること

本文

docker-ce と， nvidia-container-toolkit (あるいは nvidia-docker2) をインストールしているのに，以下のようなエラー (docker コンテナ内から GPU が見えない) が出る．

docker: Error response from daemon: could not select device driver "" with capabilities: [[gpu]].

しかもこのエラー，出たり消えたりするのだ．試行錯誤してエラーが消えたと喜んだら，1ヶ月後に突然に再発する．再発までの間に， apt のパッケージ更新や，設定の変更は一切行なっていないのに．

この問題で2ヶ月ほど苦しんだのだけど，ようやく原因が判明した． apt でインストールした docker-ce とは別に， snap パッケージの docker がインストールされており，競合していたのだ． snap 側の dockerd が起動してしまうと，バージョンが古く， container-toolkit も入っていないので， GPU が見えないという仕組みだった．ややこしいのは， GPU が見えない事以外は正常に動作してしまうので，競合していることに気付けなかった．

以下のコマンドで snap パッケージを削除することで，競合が起こらないようにできた．

% snap remove --purge docker 

(--purge フラグが必要． purge フラグがないと，イメージやコンテナを保存しようと圧縮するので長い時間がかかる上に， remove 後もストレージを消費し続けてしまう)

さて， snap で docker をインストールした記憶はないので，原因を調べてみた．Ubuntu 20.04 のインストーラを実行していた時間に， cloud-init が snap で docker をインストールしている記録が見つかった．どうやら，私が Ubuntu インストーラの選択肢を間違えて，不要な snap package をインストールしてしまったらしい．

2020-12-** **:**:**,*** - util.py[DEBUG]: Running command snap install --channel=stable docker with allowed return codes [0] (shell=True, capture=True)

_ Ubuntu 上の Evince で UIM を使うための Apparmor の設定方法

Ubuntu 18.04 上で Apparmor をデフォルト設定のまま有効にすると， Evince で UIM が有効にならない． この問題を解決するには /etc/apparmor.d/local/usr.bin.evince に以下の記述をして， sudo service apparmor reload すれば良い．

owner /run/user/*/uim/socket/uim-helper w,
/var/lib/uim/installed-modules.scm r,
/var/lib/uim/loader.scm r,

なおこの解決方法は，2011年に 射撃しつつ前転 改: evinceでuimが使えない問題を解決する で示された解決方法を適用したシステムで， apparmor パッケージの更新で設定ファイルが上書きされそうになったことから，必要と思われる行を local ディレクトリのファイルに抽出したものである． この対処によって，パッケージ更新に対してロバストになったと期待される．

_ Nexus 6P 不具合により交換

純正ACアダプタ + 純正 USB-CtoC ケーブル で充電できない不具合が発生して，保証交換になった．

具体的な状況は，ケーブルをつないでも充電状態にならず，通常の待ち受けよりも早く (5〜10倍程度) の速度で電池を消耗するというもの． ケーブルの繋ぎ直しや，裏表の差し替え，エアダスターによる埃の除去は，効果がない． この状態でも，もう1つの付属ケーブル USB-AtoC を使えば，通常速度の充電は可能だった．

効果があるのは電源オフのみで，電源が切れると速やかに充電状態になる． 電源オフをすれば，その後に起動しても急速充電状態になり，しばらくの間は問題が発生しない．(だが，時間が経過すると再発する) 再起動で一時的に回復ところから，充電制御まわりの異常と推察される．

初期化しても直らないため，保証交換になった．

同様の問題に心当たりがある人は，保証期限が切れないうちにサポートに問い合わせることをお勧めする．

_ Surface Pro 4 不具合により交換

Connected Standby (サスペンド) 中に，前触れなく電源が切れる問題が発生し，保証交換になった．

バッテリ残量が十分な Surface をサスペンドから復帰させようとすると，0から起動が始まることが，1〜3日に1度くらいの頻度で起こる． イベントビューアで見ると， 6008 エラー (予期せぬシャットダウン) が記録されているが，前兆らしきものは見当たらない．

電源+音量ボタン長押しによる再起動や，初期化を試しても直らないため，保証交換になった．

同様の問題に心当たりがある人は，保証期限が切れないうちにサポートに問い合わせることをお勧めする．

_ [linux] Ubuntu 16.04 に上げたら名前解決が妙に遅くなった問題

解決策: IPv6を使っていないなら，無効化しよう． sysctl.conf に2行書くだけ．「今が二千何年だ」とか気にしてはいけない．

twitter で「名前解決が遅いよー」と泣き言を書いたら， @kawazoe 氏が「AAAA引きに行って待ってるんじゃないの?」と，ピンポイントで正解を指摘してくれた．さて，Aを優先するにはリゾルバの設定変更が本筋だろうだけど，そもそも IPv6 を使ってない (IPv6の回線を契約しておらず，LAN 内で自動的に使われるときだけ IPv6 になってたかも知れない) という状態だったので，IPv6 を無効化することにした．LAN内のAndroid端末でも名前解決が遅い気がするし．

調べてみると情報がいろいろあるが，とりあえず /etc/sysctl.conf に，下の二行を記入して適用すれば， network interface から v6 アドレスを取り除くことができた．

net.ipv6.conf.all.disable_ipv6 = 1
net.ipv6.conf.default.disable_ipv6 = 1

kernel の IPv6 機能全体を無効化するには， kernel の起動オプションを設定すればよいらしい．こちらはまだ試していない．

結果として，名前解決は劇的に早くなり，ウェブページの読み込み完了までの待ち時間は1/10以下になった．

_ [windows] Bootcamp 領域の Windowsを VMware Fusion からも起動していた人は，うかつに Windows 10 にアップグレードしてはいけない

大前提: 過去には，Bootcamp領域のWindows 7をVMware Fusion等の仮想マシンで起動することは，Windowsのライセンス1つで，Microsoftが許可していた． しかし，ある時点から方針が変更され，この場合に2つのライセンスを要求する事になった． 過去に仮想と物理の両方でアクティベーションされた環境が，自動的に無効化されることはなかった．

小前提: Windows 10 へのアップグレード後には，古いOSでのアクティベーションは無効となり，新規にアクティベーションが必要となる

結論: 1ライセンスで物理・仮想の2つの環境にアクティベートされたWindowsを，Windows 10 へアップグレードすると，片方はアクティベートできなくなる

大前提に気付いてなかったので，Windows 7 から Windows 10 へのアップグレードで，仮想マシン側でアクティベーションできない状態になってしまった．Windows 7 に戻して，アクティベーションが復活するかどうかは未知数．

5月13日追記: Windows 7に戻したら，物理と仮想の両方でアクティベーションが復活した．

_ [linux][windows] VMware Workstation 12.1 for Linux の Guest Windows 8 で ScanSnap S1500 が正常動作しない問題

回避策: Guest VMの構成を変更して，USB Controller を 3.0 から 2.0 にする．

検索に引っ掛かりやすいように，できるだけキーワードを増やしておいた．

ScanSnap Manager を使うために VMware WS 内でWindowsを動作させていた．しかし，VMware WS 12.1に上げたタイミングで，1ページ目のスキャン後にScanSnap Managerの動作が止まり，スキャナのランプが点滅してしまう (その結果，1ページ目もそれ以降もスキャンできない) というトラブルにぶつかっていた．

原因はVMware WS 12.1のUSB 3.0サブシステム(?)にあるようで，VMの構成をUSB 2.0に変更し，ゲストOSを再起動したら今まで通りスキャンできるようになった．

_ (9月18日 更新) 元の文字サイズの比率を保ったまま，文字サイズを拡大縮小する bookmarklet

今時のブラウザでは，ズームイン・ズームアウト時にページ全体が拡大・縮小されるのがデフォルトになっている． これは大抵の場合において便利だが，レイアウトと画面幅の都合で「文字だけ大きくしたい」という場合もある．

Firefoxには「文字サイズのみ変更」というオプションがあり，ページ幅や画像サイズを固定した，(昔ながらの)文字のみの拡大縮小も可能だ．しかし，このオプションはグローバルで，タブやページだけに限定できない．(同時に開いている他のページが全て，文字サイズのみの拡大縮小になってしまう)

「そんなときは bookmarklet だろう」と検索してみたものの，意外にも痒いところに手が届くものが見つけられない．私の要望は，「拡大縮小の際に，ページ内での文字サイズの比率を保っていて欲しい」(ブラウザの標準機能と同じ振舞い) というもの．しかし，見つかったのは，ページ内の文字を一律で一定サイズにするものや，cssでfont-sizeが明示的に指定されている要素は比例して拡大縮小されるが，明示的に指定されていない要素(継承している要素)の文字のサイズは一旦リセットされてしまうものだった．

少し調べてみると，getComputedStyle という関数で「その要素に現時点で設定されているスタイル」を得ることができるとの事． (参考) これを利用して後者のbookmarkletを改善すれば，全ての要素を比例して拡大縮小できそうだ．

というわけで，下の bookmarklet を作ってみた．

• 比例した拡大
• 比例した縮小

動作確認は， Firefox 39 と Chromium 43 で行なった．

追伸: 「もっと良い方法があるから，こんなゴミは消せ」という情報をお待ちしてます．

更新履歴

2015-08-04

parseIntで小数点以下を捨てていたのを，parseFloatに変更した． 古い版にあった下の2つの問題が解決した．

1. 何度拡大を実行しても 3px 以下のフォントは大きくならない
2. 拡大と縮小を交互に繰り返すと，要素毎のフォントサイズの比率が狂う

2015-09-17

高速化．css の font-size プロパティが設定されていない要素や，相対指定されている要素にはサイズ設定を行なわないことで，要素数の多いページでも短時間で処理が完了するようになった．

2015-09-18

昨日の高速化に欠陥がある(style属性以外でフォントサイズが指定されていると拡大縮小の対象から外れてしまう)ことが分かったので，差し戻し．早いが欠陥のあるバージョンは，下に残しておく．

• 比例した拡大(欠陥あり)
• 比例した縮小(欠陥あり)

_ OS X 10.9 (Maverics) + iMac 27 late 2009 + Fan Control による不具合

Mac OS X 10.9 (Mavericks) は不具合面でいろいろと話題になっているが，うちも微妙なトラブルを踏んだ．

• ブラウザ (Google Chrome) の動作や，アプリケーション切り替え時に頻繁に引っ掛かり (いわゆるプチフリーズ) が起こる
• kernelが下のようなエラーメッセージを大量に出力し続ける

SMC::smcReadKeyAction ERROR TH0P kSMCBadArgumentError(0x89) fKeyHashTable=?????

10.8 およびその前のバージョンの頃から，熱暴走を防ぐために Fan Control をインストールしてファンの回転数を高めており， Mavericksにアップグレードした時にもそれを引き継いでいた． 実は，この Fan Control が不具合の原因となっていた． Fan Control をアンインストールすることで，プチフリーズが起こらなくなり， kernel のエラーログも出なくなった．

熱暴走を防ぐという必要性には変化がないので，温度変化を観察して，何らかの対策を取る必要がある．

_ 英辞郎第七版を，手動で Mac にインストール

英辞郎第七版 は， Mac 用の辞書データインストーラが正しく動作せず，インストールできないと評判 なのだが、私の手元でも同じ結果になった． 仕方がないので，インストーラを手動で展開し，辞書データを取り出してインストールすることにした．

困っている人が多いようなので，私の行った手順を記録しておく．

• Mac用のDVDをマウントする
• ターミナルで以下のコマンドを実行する

> cd /tmp
> xar -x -f /Volumes/EIJIRO_VII/fscommand/eijiro7install.pkg
> cd 英辞郎.pkg
> gzcat Payload | cpio -i
> sudo cp -r 英辞郎.dictionary /Library/Dictionaries/
(パスワードを入力)

• 辞書.app (Dictionary.app) の辞書一覧に「英辞郎 第七版」が加わっていることを確認する． (メインウィンドウのリストに表示されない場合は，辞書.app の環境設定の一覧にないか，確認する．)

注意事項

辞書データは著作物なので，ライセンス違反をしないよう注意してください． インストーラが正しく動作した場合と同じ結果になるだけなので， この知識を悪用することはできないと思いますが，念のため．

_ 今日の日記の要旨

skype を 64bit linux にインストール後しばらくすると「Please reinstall Skype」 というメッセージが表示される場合には， root で prelink -u -a した後に prelink パッケージを削除することで問題が解決するかも知れない．

……って事のためだけに，だらだらと長文を書いたというのが真の要旨か．

_ [linux][debian] skype と prelink と amd64 の微妙な問題

最近は amd64 なディストリビューション向けにも skype のバイナリが用意されている．……がこれは実は，32ビットバイナリをパックして，64ビットディストリビューションにインストールできるよう依存関係を記述しただけのモノ．今回は，それが原因でいろいろとハマったという話．

skype を debian/amd64 な環境にインストールしてしばらくすると，標準エラー出力に以下のようなエラーメッセージが表示されて， skype が起動できないようになる．

/usr/lib/gio/modules/libgvfsdbus.so: wrong ELF class: ELFCLASS64
Failed to load module: /usr/lib/gio/modules/libgvfsdbus.so

同時にエラーメッセージの表示されたダイアログが表示される．エラーメッセージは「Please reinstall Skype」．

確かに，メッセージに従って skype のパッケージを再インストールすると症状は一時的に改善される．……が，何日か経過するとまた起動しなくなってしまう．そもそも，なんでパッケージの再インストールでダイナミックリンクの問題が直るんだ．こんな訳の分からん問題のために，何十MBのファイルを再インストールするなんてやってらんねー．

コンソールのエラーログの意味は，32ビット実行ファイルが64ビットの共有ライブラリを読み込もうとしてエラーになっているという事．しかし，インストール直後は大丈夫なのに，後からおかしくなる意味が分からない．

このあたりのメッセージを検索して原因を調べてみると，関係がありそうで無いページ*1が大量に引っ掛かるのだが， 答えが載っているのはこのフォーラムの議論だった．

どういう問題だったかというと， prelink という，オブジェクトの動的リンクを事前に計算しておいて，プロセスの起動 (正確には exec 後のダイナミックリンカの処理) を高速化する仕組みがある．これが，64bit環境にインストールされた 32bit オブジェクトを取り扱う際に，誤って 64bit のライブラリをリンクするように指定してしまうという事があるという事のようだ． prelink は cron で定期的に実行されるので， skype のパッケージをインストールした直後には prelink が効いておらず，そのため正しく起動する．

さて， prelink は計算した動的リンクの情報を記録するために，実行ファイルを書換えるようだ．この情報を削除するためには，実行ファイルを書換える権限のあるユーザ (早い話が root) で「prelink -u 実行ファイル」というコマンドを実行すれば良い．とりあえず，上記のコマンドで skype から prelink の情報を削除して， skype を実行してみると問題なく起動するようになった．あとはこの状態を維持できれば良いのだが， cron で prelink が実行されると元の木阿弥になってしまう． prelink が skype の実行ファイルだけを無視するように設定できれば良いのだが，どうやらそんな都合の良い仕組みは無さそうだ．

cron で prelink が実行された直後に prelink -u を実行するというのも一つの手だが，そんな面倒な事をするより prelink 事態を削除してしまおうと決めた．具体的な作業としては， prelink -u -a を実行したあとに， prelink パッケージを削除．おそらく，ダイナミックリンカの処理が占める割合は昔に比べて減っているので，性能への影響は微小だと予想される．