AURのpandoc-static

AURのpandoc-staticパッケージが更新できず詰まっていたので、記載。

pandoc-staticがicu<54を要求しているために起きていた。 この問題は既に報告され、修正したとしているが、それでも以前問題があった。

更新のしようがなくなってしまっていたので、pandoc-staticを削除してからアップデートし、そしてpacndoc-staticを入れなおす。

だが、GnuPG鍵が確認できず、エラーになる。 これも解決したとしているが、解決されていなかった。

gpg --keyserver pgp.mit.edu --search-keys fauno

でいけた。

LGディスプレイの顛末

まぁ、次の通りだ。

LGの回答
LGの回答
  • 色がおかしい→否定&交換(下記と同一)
  • 画像がおかしい→肯定&交換
  • アダプタが鳴く→否定&交換

結果としては

  • 画像がおかしい、という点は直った
  • 色はやはり白いが、色が出ていないという部分は直った
  • アダプタの鳴きは多分直った
これでみても右が白っぽく色も出ていない
これでみても右が白っぽく色も出ていない

結論としては

  • フォームで散々サポートを拒否した上、今回も受け取りも経過報告も一切なしで送ってきたので、結構苛立つ
  • 製品品質もひどい
  • 今後LG製品を買うことはないだろう
  • 素直に交換されているので、最終的にはダメだったわけではない(品質は悪いが)。経過や品質を気にしない人はいいと思う。
  • 少なくとも詐欺商品の類ではない
  • 品質に関して、高級なやつは違うのかもしれないけれど、それは分からない。22EN43と22EN33がこれだけ品質が違うので大いにありうる

デスクトップは起動しなくなり、ラップトップはこわれ

Manjaroのプリンター問題

Manjaroのプリンターが全く動かない、という問題。プリンターを追加しようとするとフリーズするわ、KDEでマニュアルPPD指定だとボタンが無効になり、さらにプリンターの名前が反転される、というわけのわからない状態。挙句、成功などと言われてしまうのでどうしようもない。

散々試してもうまくいかず、試しに500GB HDDにManjaroを入れてアップデートして試したが、同じ症状が出る。だが、その過程でUnable to get list of printer driversというメッセージを獲得し、これがヒントとなった。

最終的には

ArchWikiの情報
が活かされて、Foomatic関連を削除することで解決したのだが、この過程でUEFIブートメニューからmanjaroがHDDのものだけになり、Windows boot managerが2つ、空行がひとつ、という状態になった。

UEFIブートトラブル

さて、それでUEFIからブートできないというトラブルが生じたのだが、調べるとUbuntu Boot Repairを使うという提案がかなり多い。そこで試したのだが、Boot Repair Diskを使っても、Ubuntu 14.10を使ってもアンマウントしろと言われて進まない。問題自体は

Ubuntuのforum
で報告されているが、これに従っても解決しない。


Manjaro Wiki
に従って復旧を試みたが、EFI variables are not supported on this system.エラーから抜けられない。記載の通り対応しても、efivarsは動いているにも関わらず、modprobe: FATAL: Module efivars not found. と言われてしまい詰まってしまった。

最終的には、2つ目のWindows boot managerがManjaroを起動させることに気づき、そこからgrub-installを実行して修復できた。ただし、Windows boot managerは相変わらず2つある。

ラップトップのWindowsは完全死亡

その間を支えてくれた復活したてのe440だが、Windows Update中にスリープされてしまい、その影響で構築に失敗するようになり、多くの基本的なものを含むプログラムが起動しなくなり、トラブルシューティングツールでも復元ポイントでも失敗するという状態。

Updateの時はスリープしないようにするくらい当たり前のことだし、せめてトランザクションを張れと思う。

自動再起動の餌食になって、コピーしているファイルや録画が潰されることも多い。

もうこの状態ではe440は初期化するしかない。非常に腹立たしい。

名刺印刷でトラブル

新しい名刺の仕様を確定し、A-ONEの名刺用紙(2×5)で印刷しようとしたのだが、普通OAペーパーにテスト印刷した時点で明らかにズレていた。

データを検証したが原因がみつからず、印刷設定を確認したが問題はみつからない。以前はマージンが設定されていたが、現在はされていないのが原因かと思って確認したが、マージンを増やすとさらにズレる。また、用紙をA4でなくデフォルトのままにするとどうかと思ったが、悪化する。念の為、OkularではなくEvinceから試してみたが同様。PDFにせずInkscapeから直接SVGを印刷すると位置は同様、内容はさらに悪化した。

データが問題か印刷が問題かを切り分けるため、あまくいっていたPDFデータをプリントするとやはりズレる。これで、問題は印刷にあることが分かった。

Manjaro Linuxが持っているドライバを疑い(前回はopenSUSEから行っていた)、Sabayon Linuxで印刷してみたが結果は同じ。そしてWindowsで試してみることにした。Acrobatから印刷すると、結果は違うがだいたい似ている。ただし、Linuxで印刷すると青紫がかなり赤くなってしまう問題は解消された。カラープロファイルについて修正が必要なようだ。

そしてAcrobatが持っている印刷プロパティの設定でActual sizeとChoose paper source by PDF page sizeを有効にしたところうまくいった。

Linux上で解決していないので、問題自体はpendingだが、とりあえずうまくいってよかった。

Manjaro LinuxのXが起動しなくなった

12-20のシステムアップグレードリリースでManjaroを再起動した際、Xが起動しなくなった。

[ 32.722] (II) fglrx(0): Desc: AMD FireGL DRM kernel module
[ 32.722] (II) fglrx(0): Kernel Module version matches driver.
[ 32.722] (II) fglrx(0): Kernel Module Build Time Information:
[ 32.722] (II) fglrx(0): Build-Kernel UTS_RELEASE: 3.18.0-0-MANJARO
[ 32.722] (II) fglrx(0): Build-Kernel MODVERSIONS: no
[ 32.722] (II) fglrx(0): Build-Kernel __SMP__: no
[ 32.722] (II) fglrx(0): Build-Kernel PAGE_SIZE: 0x1000
[ 32.722] (II) fglrx(0): [uki] register handle = 0x00016000
[ 32.722] (II) fglrx(0): DRI initialization successfull
[ 32.722] (II) fglrx(0): FBADPhys: 0xf400000000 FBMappedSize: 0x010e0000
(==) Log file: “/var/log/Xorg.0.log”, Time: Sat Dec 20 23:57:18 2014
(==) Using config file: “/etc/X11/xorg.conf”
(==) Using config directory: “/etc/X11/xorg.conf.d”
(==) Using system config directory “/usr/share/X11/xorg.conf.d”
(WW) fglrx: No matching Device section for instance (BusID PCI:0@0:1:1) found
/usr/bin/Xorg.bin: symbol lookup error: /usr/lib/xorg/modules/drivers/fglrx_drv.so: undefined symbol: GlxInitVisuals2D

検索すると事例はかなり多く見つかるが、そのほとんどはaticonfig –initialしろというものだ。

だが、これでうまくはいかなかった。nomodesetしろという声もあったが、それはすでにしてあるし、確認もした。

そのほかにはflgrxを無効にする方法について記述されたものがある程度で、それ以外はインストールしろか、もしくは解決しないままか、だ。

かなり深く調べた。エラーでは0:1:1となっているが、本当にBusIDの不一致を疑って調べると0:1:0だったので、それが原因かと思って調べたりもした。だが、結局解決にはつながらなかった。

バックアップしたイメージでロールバック、ということも考えたのだが、まずは総再ビルド&インストール。もし、パッケージが壊れたためならこれで解決する。もともと壊れていたのなら、ロールバックしてアップグレードしても同じことになる。

やり方は次のようなもの。

for i in $(pacman -Q | cut -f 1 -d " ")
do
yaourt -S --noconfirm "$i"
done

sudo時間は長くしておくほうが良い。

だが、うちの場合、頻繁に、長時間に渡ってネットワークダウンが生じる。上流で起きていること(おそらく、回線、集合回線部分のせいだろう)なので私には手出しできない。フルビルドで回っている間ネットワークがダウンすると失敗する。これはなかなか恐ろしい。

幸いにもネットワークダウンには遭遇せず2回完走したのだが、改善しなかった。そこでロールバックを試みたのだが、dumpしたイメージをrestore(8)しようとしたが、0 inode fileと言われ、14GBもあるファイルにもかかわらずできなかった。

システム再インストールしかなくなってしまったが、せめてもということで、pacman -Qの結果を外部に保存しておく。

再インストールだが、Manjaro 0.8.11 Xfce JPのイメージのインストーラではkeymap選択画面でフリーズしてしまい、進まない。0.8.10 XFce JPイメージでインストールする。

2014-11-05のarticleにある手順でセットアップ。

  • pacman-keyの再構築、無効なキーの削除
  • aticonfig
  • vigrでusersのGIDを500

そしてパッケージを復帰させる。いくつか試したが、sudoのtimeoutを無効にした上で

for i in $(ruby -e 'list1 = `pacman -Q | cut -f 1 -d " "`.split("\n")' -e 'list2 = `cut -f 1 -d " " paclist`.split("\n")' -e 'list2.each {|i| next if list1.include?(i); puts i}' )
do
yes Y | yaourt -S "$i"
done

--noconfirmではconfrict時に中止を選択されてしまう。基本的にはこれで通るが、MATE関連でgstreamerかpulseaudioか選べと言われてYを返しても通らないため、チェックしてこの時に一旦INTしてmate関連を手動インストールの上、やり直す。ちなみに、依存関係で入るパッケージもこの方法だと再インストールするため、mozc-utなどはfcitx-mozc-utで入るのだから途中で中断してやり直したほうが早い。

これを避ける方法としては

while p=$(ruby -e 'list1 = `pacman -Q | cut -f 1 -d " "`.split("\n")' -e 'list2 = `cut -f 1 -d " " paclist`.split("\n")' -e 'list2.each {|i| next if list1.include?(i); puts i}' | head -n 1)
[[ -n "$p" ]]
do
yes Y | yaourt -S "$i"
done

で、その他の選択肢を要求する場合を除いていけると思う。だだし、そもそもビルドできないパッケージがあると、それはインストールできないため詰んで(ループして)しまう。監視なしにするにはexpectを使うしかない。なお、xpdf関連は無理だった。

この後は次のようにしてセットアップを進める

  • バックアップしたhomeのイメージをrsync。この時、rsync -av /mnt/1/ –exclude share/ /home/としてマウントされるユーザーデータは回避する。
  • このままではユーザーデータがマウントできないので、sudo -u aki mkdir ~aki/share ~aki/.share.encfsとする。
  • /etc/fstabを編集。tmpfsと~/.share.encfs(btrfsサブボリューム)のマウントを設定。 encfsをマウントするためのスクリプトを~/root/binに書く。
  • これでほぼ通常通り。リブートしてakiでログインし、Catalyst Control Centerを起動、設定すればOKだ。復旧に6日もかかってしまった。
  • 今回のようなことがか内容にと、今回はインストール時にLVMを使用する設定とした。ちなみに、ディスクのパスフレーズの強度を大幅に高めた。
  • だが、標準でLVにVG全域を使用してしまうため、「管理やバックアップを容易にするため」と言いながら、実際は全く柔軟性がない。仕方ないので、SystemRescueCDで起動し、luksOpenしてvgscanし、ルートボリュームをe2fsck+resizefs+e2fsckで縮小した後、lvreduce --size 80G ManjaroVG/ManjaroRootでOK。アップデート前にスナップショットを取るようにすればロールバックは容易になる。Manjaroでは運用中にこのような事態に陥ることが既に3回めなので必要だろう。また、rsyncでバックアップしておくことも必要かもしれない。

Linuxトラブルとの格闘

15日、Manjaroが起動しなくなった。systemdが途中で沈黙してしまう、という症状だ。

systemdが、となるとそう簡単ではないため、とりあえずMageiaに戻ったのだが(もちろん、home directoryにおける様々な問題が生じた)、17日、そのMageiaに致命的な現象が生じた。

極めて重くなったため、topしてみると、nepomukfileindexなるプロセスが非常に激しく動いている。これはなんだ?

とりあえず再起動してみると、fork bombが発生した(konsoleが27 windows開いた)。nepomukのせいか!?

ファイルアクセスが激しいということはデータを盗み出す類のプロセスである可能性が高いと判断し、直ちにイーサネットケーブルを抜いて、別システムのインストールを行うことにした(今インシデントを扱える状況ではない)。

Manjaroを潰してSSDにMageiaをインストールすることにしたのだが、Btrfsが扱えない、LUKSをかけるとパスワードが入力できないなどのトラブルで何度も再インストールを余儀なくされた。

なお、Manjaroの再インストールもこの過程で何度もトライしているのだが、pacman-key –populateに失敗するためどうしようもなかった。どうもForumにあるこのケースと同様のようだが、相当苦戦しているで容易ならざることか。このフォーラムでも解決していないようだ。

特に注意してほしいのが、インストーラでキーボードレイアウトにJPを選ぶとJPキーボードでインストールされる。ところが、ログインするとその状態ではinput methodが何も設定されておらず、iBusはUSキーボードのレイアウトで入力させる。そのため、記号を含むパスワードを設定しているとキーボードレイアウトの違いからlogin incorrectとなる。

なお、KDMではJPキーボードでインストールしているのであれば自動的にJPキーボードの配列で入力することになり、ログインは通常通りできる。このことでだいぶハマった。

しかしセットアップしていくと、再びnepomukが顔を出す。何者なのだこいつ。

そこでrpm -qfしてみると、nepomuk, nepomuk-core, kde-coreに含まれていることが分かった。調べてみると、まっとうなプロジェクトで、それを積極的に利用している例がKDEだという。

ではあのfork bombとは別ものだったのか。あの妙な挙動は何だったのか。

分からないのだが、とりあえずは安心していいのだろうか。もちろん、virus checkもすませてあり、問題はほぼなかった。少なくとも懸念していた問題はみつからなかった。漏洩調査が必要だが、これはかなり難しい。また、汚染調査の追跡は、これから行うことになる。これもしばらくかかるだろう。パスワード変更作業などが迫っている。

ついでなので、インストール時点で/varを別に切りLVM上に置く、SSDにインストールするなどの懸案を片付けた。また、これまではhome directory(/homeとは別に、/home/user)にマウントしていたのだが、dor filesに非互換が生じることがあるため、この解決のために/home/user/shareにマウントするようにした。共有すべきdot filesをsymlinkにすることでdor filesなどの共有問題を解決し、基本的にはデータ共有とすることで問題及び影響を生じにくくした。

share下にあるディレクトリの設定上の問題(~/binなどでもある)が生じるため、従来通り~/localのpathを維持するため、~/localは../share/localのsymlinkとした。

今回の作業でよくわからない変化があった。

まず、gtk-query-updateをしてFirefoxで正常に日本語入力が可能になった。これまでなぜできないのか分からず様々な方策を試しているような状態だったのにだ。一方、meditはIMEは機能するが入力できない状態、つまり変換も確定もできない状態となっている。