MageiaからManjaroへ

Manjaroのセットアップ

Mageiaのパッケージ管理ツールのまずさというのが、「削除がうまくいかない」ことにある。Wineインストール時に一度選択して、その後選択解除するとごっそりパッケージを抜かれる。そして、もう一度選択しても抜くパッケージを選択してくれない。

わかっていたのにやってしまった。KDEやKDMなどがごっそり抜かれ、修復困難な状態に。動かない、ということはないのだが、グラフィカルスクリーンを立ち上げることができないため、諦めたほうが早い。

翌日(今日)がopenSUSE 13.2のリリースdayだったので、1日待ってopenSUSE 13.2にしようかとも思ったのだが、まずはManjaroに挑戦してみることにした。「あっ、やっちゃった」と思ってリブート前にManjaro Linux 0.8.10 XFce JPを焼いておいた。これは、以前のものからはちょっと更新されているほか、以前はライブCDの部屋のCinnamon日本語版だったが、今回はManjaro JPのものにした。

以前はGPGキーリングの問題が出てインストールできなくなってしまっていたが、今回はバージョンを上げて再チャレンジ。

しかし、以前のものはとりあえずXが落ちるところまではいくのだが、UEFIブートだとnomodeset, nokmsbootでもブートスプラッシュまで行かない。USBからのブート(BIOS)なら行くし、Xが落ちる。しかし、オプションなしではシステムが落ちる。

UEFIの場合、グラフィックタイプ別のmodeset設定がされており、それを消せばnoXまでは行く。しかし、CUI testingインストーラではいまいちうまくインストールできない。CUI stableインストーラでBIOSブート、というのも悔しいのでいろいろ試していると、nokmsboot+nomodeset+non-free driversでいける、ということがわかった。これであればライブ起動するため、「普通に」インストールできる。

「普通に」UEFIブートでGPT使ってインストールしたところ、UEFIのブートメニューにmanjaroという項目が登場する。これであとは起動時にブートオプションをつけることを忘れなければ(eキーでeditし、linuxの行にnomodeset,nokmsbootの2項目を追加)普通に起動できる。が、アップデートできない(!)

gnupg cannot locally signのエラーが出るのだ。これは以前と同じ問題。ここで躓いてしまうと諦めるしかない。調べると、答えが載っていた!(以前はなかった)

Manjaroフォーラムの情報に従い

# mv /etc/pacman.d/gnupg /etc/pacman.d/gnupgold
# pacman-key --init
# pacman-key --populate archlinux manjaro
# pacman-key --refresh

とすることで進む(–initはかなり時間がかかる)。が、やはり検証できない鍵があり、アップデートに失敗する。

ネットランナーの記事を参考に

# sudo pacman-key -r 604F8BA2
# sudo pacman-key --lsign-key 604F8BA2
# sudo pacman-key -r AC97B894
# sudo pacman-key --lsign-key AC97B894

とすると通った。

あとは以前の通り、Forumの情報にしたがって

# pacman -Syu
# aticonfig --initial
# mhwd-kernel -i linux314

でいける。314でなくても良い気もするが、とりあえず314にしておいた。これでCatalystで起動してくれる。

Manjaroは比較的豊富なパッケージを導入している。encfs, ecryptfs, btrfs, LVMなども最初から入れており、比較的難なく継続利用することができる。

ただし、UIDが1000、GID(users)が100を割り当てるため、互換性に乏しい。ここは統一ルールとして

  • 一般ユーザーのUIDは1000から始める
  • usersグループのGIDは500にする

というルールを設けてvipw及びvigrで編集する。

さらにホールディレクトリの設定は不十分だったので、これも改善しておく。基本的に共有される部分が~/shareにマウントされるサブボリュームであり、ホームディレクトリ直下で使われるものについてはシンボリックリンクで対応する。

home-aki-shareサブボリュームはすでに用意されているが、これまでhomeサブボリュームに自身のホームディレクトリが含まれていた。homeサブボリュームを新たに作り、従来のhomeサブボリュームは「Mageiaのhome」と理解する。また、統一ルールのため、従来のshareサブボリュームについては、chown -R aki:users /mnt/4することで修正する。もちろん、「Mageiaのhome」に未整理のまま取り残されているファイルも存在する。だが、ホーム直下に置き去りにすることはあまりないので影響は少ない、はずだ。こういう時のために~/home/share/jumbleディレクトリでも用意しておこうか。(本来はshare直下にそれをする予定だった)

基本的なものは揃っているが、zsh, git, ruby, sox, fetchmail, claws-mailがないためそのままでは動かない(vlcに関してはMageiaで作りこんだ仕様よりも気持ちよく動く)。これらをインストール。また、mikutterのためにはbundlerをインストールした上でbundleする必要がある。また、iron(SRWare iron)はライブラリがないため動かないし、ironはAURにもない。ただし、MaxthonやOpera developerはAURに存在する。

AURにはlvとnkfもあるので、これも導入しておく。

fontconfigに関してはlocal.confもUserconfも反映してくれない。優先度を99にしても反映されない。これについてはわからないのでpending.

次にオーディオ設定だが、デフォルトでpulseaudioに依存したシステムを組んでいるのでなかなかややこしい。pulseaudioを消すことはできるが、そうするとそのままでは鳴らないプログラムもあるかもしれない。

pulseaudioがなぜ嫌かというと、まぁ、強制的に16bit/48Khzにするからであり、音が悪いからなのだ。USBオーディオインターフェイスを使っている(24bit/92kHz)私としては「なんとももったいない」。ただし、実際はハイレゾ音源なんて制作以外で扱うことは滅多にないし、pulseaudioを外したところで快適なプレイヤーで再生する状況ではないので、わざわざpulseaudioをパージしなくても、どうしても聴きたい時だけalsaplayerだと思うが。

pulseaudioとはなにかというと、簡単に言えばオーディオドライバに対する高レベルAPI(サウンドサーバー)だ。pulseaudioを経由してesound, oss, alsaといったサウンドサーバー、サウンドドライバーから音を出すことができ、扱いやすく統一した取り扱いを提供する。つまり、プログラマ的、コンピュータ的な論理化、抽象化を提供するレイヤーというわけだ。もしかしたらpulseaudio-jackなんてものもあるかもしれない。だが、確実に鳴らすために16bit/48kHzに変換するし、そこで遅延が生じるし音も悪くなる、という。

ALSAでがんばってみたのだが、Audio4DJは4chあり、Cahnnel B(Headphone monitor)から出したいのだが、ALSAだとChannel Aから出てしまう。結局諦めて、pulseaudio-managerの設定でデバイスを設定(デバイスごとに出力チャンネルが選べるので、Amarok起動状態でAudio4DJのチャンネルをBにし、Amarokの出力をAudio4DJにする)することでAmarokでスピーカーが鳴らせるようになった。

AmarokはGstreamer backendでPulseaudio経由の設定でビルドされている。Xine backendのほうが音がいいのに…Pulseaudioの音はちょっと平べったいけれど、割とスムーズなのと、従来(AmarokでPhononがAudio4DJを出力デバイスにする)はフォーマットが異なる場合などに音が鳴らないままシークが進み、音がバグるトラブルがあったが、それがない。I doというmp3の音源はまともに再生できなかった、ということも解消された。遅延はあるにせよコントロールはしっかりしているので、必ずしも「音が悪い」とは言えないかもしれない。ちゃんと安定して演奏できることは大事だろう。「いい音で聴きたい音楽のみAmarokを使うことで確実にAudio4DJ+Sonyスピーカーから出て、他の音はlogicoolスピーカーから出る、という扱いの良さや意図した通り環境によらず鳴ってくれる点を含めてもしかしたら結構いいのかもしれない。

Manjaro XFce JPの使い心地

ManjaroはManjaro+Arch+AURのリポジトリを使う。AURのパッケージはかなり多く、UbuntuやopenSUSEに匹敵するパッケージがある。また、AURに集約されているため、レベルの高いユーザーの成果物がダイレクトに利用できるというのが非常に大きな魅力となっている。

ただし、もともとArchは最低限のパッケージを導入して使うものなので、それを色々入れて「初心者向け」にしていることの破綻はある。

まず、パッケージインストーラが「ひとつずつインストールを選択する」ことや、「最低限の依存パッケージをchoiceしようとする」ということがまず多くの、そして完成された高機能なソフトウェアシステムを求める人にとっては環境づくりのハードルが高いし、あまり色々いれるともともとあれもこれも入れて選択するような使い方を推奨していないのでトラブルの原因にもなる。「どのパッケージが必要か」分かっている人が余計なものは入れない方向で使うようにしないと機能しないシステムが出来上がりそうだ。

全体にはパッケージは早いがFedoraほどは早くない。それに、パッチ当てなどにあまり熱心でない(必要なら自分でやれ、というのもある)ので、性能や機能面で劣る場合もある。速さはあまりない。また、日本では人気はそれなりにあるが、日本語環境はかなり悪く(それでもMageiaよりはかなりマシだが)、パッケージやオプションが日本での使用に適さないこともある。Archは必要ならABSを使って調整するものなので、あまり余計なものを入れているといろいろ苦しい。

さらに、Japanese Fontを入れようとしたらAURにあるものはかなりがビルドに失敗する(理由は提示されない)ということもあるし、システムへの理解が足りない初心者には決して易しくない、と思う。それでいえばChakraのほうがいいのではないか。パッケージはかなり少ないし日本語は絶望的だが。

Manjaroの情報は少ないが、Forumに結構情報があるし、ベースのArchのwiki(極めて充実している)がほとんどそのまま適用できるため、総合的には情報はむしろ多い。configuration toolの類は少なく、Manjaroが調整を入れているパッケージはあまり多くない。Ubuntuもその点はあまり変わらないが、openSUSEのような「あまりわからなくてもなんとかなる」要素は希薄。

XFceはかなり進化していて、使い心地は非常に良い。のだが、細かな設定ができず使いにくい面もある。例えば、デスクトップのエッジでは4方向に(コーナーはない)最大化してくれるが、ワークスペースを使っていると、ワークスペースとつながっている部分はそのまま通り抜けてしまうようになっている。この点について、とおりぬけるかどうかの設定はない。Notify-sendの対応も悪くはないのだが、邪魔になることがある。また、KDEのようにテーマを容易に導入することもできない。

ファミリーアプリの貧弱さに関しては、最低限のインストールができるようになっているために、kateやgwenview, amarokなどを使うこともできる。ただし、この場合はkdelibがロードされるためメモリーは必要になる。とはいえパッケージでごちゃごちゃすることは回避できる。

KDEを使うこともできるが、使用するパッケージが多く依存関係も深いため、システムのメンテナンスはおそらくかなり大変になる。KDEは好きだが、そこまでするかどうかは悩みどころ。どちらかといえばAwesomeやXmonadを入れたほうがいいだろう。

XFceは使うことは想定した調整になっているが、システム音がないなど作りこまれているという感じではない。

Mageiaのアップデートほか

ファン取り付け

私が使用しているPCケースはDefine R4である。つまり、大型静音ケースなのだが、トラブルの解消につながるかと、ファンを追加することにした。

静音ケースながらファンは背面、底面、上面x2、側面と5個つけられる仕様で、背面のみ付属している。いずれも140mmだが、120mmも取り付けることができる。上面と側面については遮音材を取り外してかわって取り付ける構造だ。

静粛性が犠牲になるため(別に静音ケースを求めていたわけではないが、折角の静音ケースならば…)気が進まなかったが、一番効果の大きそうな上面に120mmを取り付けた。

ファンが、ネジ穴が切られておらず、「ねじ込むことで切る」仕様になっているのにはびっくりした。また、120mmが取り付けられるとはいえ、140mmをとりつけたほうが明らかに美しい。あまりお勧めはできない状態だった。

効果のほどは分からないが、とりあえずこれで様子を見ようと思う。

Mageiaのアップデート

ずっとアップデートはきているのだが競合でアップデートできない状態だった。いくら待っても改善されないため、競合にあったlibpng(lib64png/develとlibpng/devel)をはずしてアップデートすると成功、さらにlibpng/lib64pngのみをアップデートしても成功した。よくわからない。

openSUSE

openSUSEのノンフリーなリポジトリはサードパーティのものであるらしい。このあたりはFedoraやCentOSなどと同じか。だいぶ経っていたので忘れていた。

openSUEはパッケージも豊富でかなり使いやすい。情報がやや足りない気もするが、初心者にも勧められるものだと私は思っている。

openSUSEがsudoでターゲットユーザーのパスワードを求めるのは、/etc/sudoersにdefaultオプションとして書かれていた。Defaults targetpwという部分だが、このような設定をデフォルトにする理由は、ちょっと分からない。あまり普通な(自然な)振る舞いではないように思う。sudoの権限管理を楽にするために、自分が管理しているユーザーに限定する、という意味はあるだろうが(実際に、そのオプションを前提としてALL ALL=(ALL) ALLとしている)。

このオプションと全権設定を無効とし、wheelグループの設定を有効にし、usermod -aG wheel userすれば普通になる。

kblankscrn.kss

KDEでブランクスクリーンのスクリーンセイバーがプロセスが死んでくれず、プロセスがたまる上に次のログイン時に大量のkonsoleが起動してしまう。そのため、定期的にkillallしておく必要があったが、いつまにか直っていた。前述のアップデート前だが、アップデートできないなりにKDE関連はアップデートに成功していたということだろうか?ひっかかってるパッケージ以外はアップデートされていたとか。

VineSeed

うまく動作しなかったVineSeedへのアップグレードだが、結局base-system+task-x11-xorg+lightdmで動くことが確認された。

また、sshはopenssh-clientにあり、sshfs-fuseは依存しておらず、scpは別パッケージ(base-systemに含まれる)という。

これはパッケージングミスや、依存関係の記述ミスであると感じたため、そのように意見してみた。

AMD APU Kaveri (A7700-K) * Linux

openSUSEのメーリングリストでご教示いただき、解決したので詳細を示そうと思う。

答はここに集約されている。今井さんによると

Kaveri等のプロプラなドライバを必要とする奴は

/etc/default/grubだったかのGRUB_CMDLINE_LINUX_DEFAULT=”nomodeset”ってしておくのが良いようです。

これをやっとけばブートパラメータで必ずnomodesetされますし。

ほぼnomodesetで通る、ようだ。実際にやってみたところ、

  • PCLinuxOS 2013.12 64bit KDE Fullmonty
  • Sabayon 14.01 KDE amd64
  • Linux Mint 16 x86_64
  • Korora20 x64_64
  • Chakra 2014.02 64bit

のいずれも、通常起動ではGrubのあとはディスプレイ信号が消え、ディスクも停止し、反応もなくなるのだが、nomodesetならば正常に起動した。

ただし、PCLOSについてはXが起動せず、Chakraはsnmpd起動時にものすごく待たされるが、これは別の問題だ。PCLOSに関しては、ビデオドライバまたはカーネルによって解決することだろう。2013.12とやや古いことが、古いカーネルを使っているという問題になるのかもしれない。

さて、nomodesetとは何か?調べてみると、そのものズバリな答がArch Wikiにあった。

Catalystドライバを使っているときなど、ブランクスクリーンになったりディスプレイに”no signal” エラーがでたりするなどの理由で KMSを無効にしたい時があるかもしれません。KMSを無効にするには、カーネルパラメータに nomodeset を追加します。詳しくは Kernel parameters (日本語) を見て下さい。

どうも、openSUSEで「NoKMS」オプションを選択することで起動できる、というのはこのあたりからきているようだ。

そしてMageiaの/boot/grub/menu.lstを見てみると、nokmsbootという値がある。しかし、nomodesetとの違いは何かと思いそれを調べてみると大半はMageia関連の記事で、FedoraやArch, Gentooでもひっかかることはひっかかるもののはっきりしたことが分からない。カーネルのドキュメントを検索してもこれについてはヒットしない。結局それについてはよくわからないままとなった。

おそらくは起動時のみKMSを無効にするのだろうと想像はつくが、推測の域を出ない。

さて、nomodesetのブート時の指定方法だが、最近流行りのグラフィカルなものは大体legacy Grubのようだ。Fキーによってメニューを出すタイプだ。これは、F3を押して「起動オプション」を選択したあとESCで戻ると起動オプションが編集できるようになっている。値はスペース区切りなので、スペースで区切ってnomodesetを追記してEnterキーで起動できる。eで起動オプション編集に行けないので戸惑う。もしかしたらもっとスマートな方法があるのかもしれない。

Grub2はeで編集に行くと複数行になっているので戸惑うが、linuxという行の最後に追加する。

セキュリティインシデントの顛末

先日、Mageiaで生じたトッププロセスからのfork bombだが、そのあとシステムを再構築したあとAgrusのログを参照して漏洩確認をするなどかなり大変な作業だった。

しかし、システムを構築した段階で再びnepomukの名が復活してきた。ケーブルを抜いて他のPCで調べてみると、どうもKDEのコアが利用しているらしいのだ。nepomukを持っているのはnepomuk, nepomuk-coreだが、kde-coreにも含まれている。KDE PIM、特にKmailがこれを必要とする。

nepomukを邪魔者と考える人もいて、停止するというやり方もあるようだが、私はとりあえずnepomukとnepomuk-coreをアンインストールして対処した。害がないとしてもこんなにトップを走りつづけるようなプロセスは困る。もっとも、このトップを走り続けることはbugらしいのだが。

さらに、fork bombは別件で、kblankscrn.kssというプロセスが大量にforkされる。これはどうやらブランクスクリーンのスクリーンセイバーに起因するらしく、これで検索すると非常に多くのbug報告があがる。

結局ふたつのbugが重なって勘違いした。システムがすぐに必要で調査のために停止させられなかったためシステムを再構築という方法をとったが、結果としてそれは失敗だった。調査を先にしていれば早く問題ないと分かり、復旧できただろう。

随分と苦労したのだが、顛末はこんなもの。漏洩がなくよかったのだが、なきたくもある。

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は機能するが入力できない状態、つまり変換も確定もできない状態となっている。

EncFS on Mageia4 x86_64

Megaia4にEncFSパッケージがないので、自分で用意した。本当はeCryptFSが欲しかったのだが、どうも難しそうなので、EncFSでとりあえず代用。

まずはpbone.netでMageia5用EncFSのsrc.rpmパッケージを入手。そしてrpmbuild --rebuildしてみるが、

download/encfs-1.7.4-11.mga5.src.rpm をインストール中です。
警告: ユーザー iurt は存在しません – root を使用します
警告: グループ iurt は存在しません – root を使用します
警告: ユーザー iurt は存在しません – root を使用します
警告: グループ iurt は存在しません – root を使用します
エラー: ビルド依存性の失敗:
rlog-devel = 1.3 は encfs-1.7.4-11.mga4.x86_64 に必要とされています
fuse-devel = 2.6 は encfs-1.7.4-11.mga4.x86_64 に必要とされています
chrpath は encfs-1.7.4-11.mga4.x86_64 に必要とされています
boost は encfs-1.7.4-11.mga4.x86_64 に必要とされています

とうまくいかない。そこでrlog-devel, fuse-devel, chrpath, boostとそれに関わるものをインストールした上で試すと無事、encfs-1.7.4-11.mga4.x86_64.rpm, encfs-debuginfo-1.7.4-11.mga4.x86_64.rpm, lib64encfs6-1.7.4-11.mga4.x86_64.rpmの3つのパッケージが生成され、インストールできた。

比較的シンプルで汎用性のある暗号化ファイルシステムで、FUSEを使う分このようなケースにおいて取り扱いやすい。