• 管理者用

  • Twitter

    • @_ks マイクオンの方たちはむしろ、「うるせーこら切れよ!」っていわれたらええねん(過激派 やっぱり資料投影しますよねぇ? アイスブレイクのためとかかなー。 マイクオンもそうですが、たしかに相手のリアクションがわからなくて不安になる、ってことはありますね 1 hour ago
    • @2_5_dimension @_ks Teamsにはあったような… オンライン講義とかを想定した機能だったかなと 1 hour ago
    • @2_5_dimension @_ks そうそう、相手をミュートね(開催者権限 13 hours ago
    • @_ks 話してないときには環境ノイズ入れたくないから切りますねぇ テレワークだと窓開けてるんで、車とか飛行機の音が入っちゃうんですよねぇ。 カメラオン派が多いんですか!そうなんやなぁ…。 自分の周りではほぼないっすね! 13 hours ago
    • @_ks マイクのオンオフですか? どんなルールでしょう…? うちは帯域つらいからカメラは原則Off、くらいかなー マイクの方は話すとき以外オフが暗黙のルールですね 13 hours ago

今日は比較的好調

とは言っても、Skypeはいつの間にか死んだりしているのですが^^;
まぁそれでも、デスクトップが死ぬ訳でなし、ウィンドウマネージャが死ぬ訳でなし。比較的好調ですな。まだuptime4時間弱だけど(ぉ
しかし、今度はyumが不調。これは大学のマシンもそうだから環境依存とは限らないかもしれない。
なぜかselinux-policy-targetedパッケージをyumで更新すると、relabelの作業が止まっちゃうんだよなぁ。気になるのはrelabelのプロセスが2つ走っていること。デッドロックでも起こしてるんじゃなかろうか。素でrelabelプロセスを実行した事ないから本来2つプロセスが走るのかもしれないけど、なんか怪しい。
という訳で、大学のマシンはyumのupgradeプロセスを中断せざるを得ませんでした。おかげでupgradeは完了しましたがclear作業が実行されず。他のパッケージも巻き添えを喰った形になってしまいました。
今後はselinux-policy-targetedパッケージは個別にupgradeし、被害を最小限に食い止めるようにしよう。どうせSELinuxなんて使ってないから削除しようとしたら1300パッケージ依存性訴えられたから断念。難儀だ・・・。
しかし、ぼちぼちFedora8の情報も転がり出してもいいんだけどなぁ。インストールしてみましたは見つかるけど、やっぱ常用している人は少ないのかしら? やっぱ世の中Ubuntuか!Orz
ま、実際Fedoraにこだわる必要はないんだけどね^^; けどRPMに慣れすぎちゃったからなぁ。今更debでの管理を覚えられるか不安。逆に言えばそれくらいしか不安要素はないのだけれど(ぉ
うむむ・・・、/homeディレクトリは別パーティションだから移行は簡単。考えておこうかしらなぁ・・・。

U.N.不調の原因はOSなのか?

グラボを抜いて、内蔵グラフィックチップでLinuxを動かしてみました。
その結果、Xが死ぬことはなかったのですが、やっぱり時間が経つとタスクトレイのアイコンが1つ、また1つと死んでいきます。大学のマシンはさしてプロセスを走らせていないので気付いていないだけなのか、はたまたやっぱうちの環境がよろしくないのかどっちなんだろう。
起動してから3時間程度はまぁ何も起きないことが多いんですが、それを過ぎたあたりからプロセスが死に始めます。大学の方も家と同じくらいごちゃごちゃと起動させてみるかなぁ・・・。
ただ、いくらなんでもkdesktopが死ぬのはおかしいと思うんだよねぇ。デスクトップの背景を表示するプロセスが死ぬって、普通考えられんでしょう^^;
この場合、悪いのはOSってことになっちゃうのかなぁ? Windowsは問題なく動作してるし。
ふぅむ。けど大学のマシンは長時間付けっぱなしでもkdesktopが死んだなんてことなかったしなぁ。
それにFedoraも長らくアップグレードアップグレードで続けてきたのを思い切ってやめて、7で、しかも64bit版を新規で入れたからなぁ。7から8はアップグレードだけど、にしても不安定だったから、これは家の環境だろうとか思ったんだけど・・・。
う〜んむ。Linuxさえ快適に動いてくれれば文句のないマシン構成なんだけどなぁ。まぁメモリは増設したらいいし。2GBが上限なのが玉に瑕ではあるけど。
金が出来たらマザー買い換えるかなぁ。Winが多少不安定でも文句はなかったのに(ぉ
問題は、マザボを交換しても改善するとは限らないところか。こればっかりは分からないもんなぁ。ほんと、なんだろか原因。プロセスが堕ちた直後にdmesgとかsyslog、Xのログとか確認したけどどれも異常なし。というか情報無し。
なんか痕跡のひとかけらでもあればそっから手がかりが見つかるかもしれないんだけどねぇ。今の状態では調べるにも絞り切れてない状態。
ほんと、どうにかしてくれぃ><

PulseAudioがクラッシュしたときの復帰法

Fedora8で採用されたPulseAudioですが、まだまだ不安定です^^; しょっちゅう堕ちます。
で、プロセスごと堕ちてくれたら
$ pulseaudio -D
でデーモンを再度起動すれば済む訳なんですが、たまにデバイスの扱いに失敗するのか、デーモンは起動しているけれどデバイスを認識できない状況に陥ります。
状況として、
・いきなり音が鳴らなくなった
・PulseAudioManager(pam)でステータスを確認すると、サーバには接続しているが各情報がすべて n/a
となっていたら、プロセスが起動したままクラッシュしています。この場合、
$ pulseaudio -k
としてもデーモンプロセスが死にません。
解決法は、/tmp/pulse-`whoami`/pidファイルに書かれているプロセス番号のプロセスを強制KILLです。具体的には、
$ kill -KILL 1234
です。1234は上記のファイル内の数字に置き換えてください。うまくプロセスを殺せたら、
$ pulseaudio -D
でデーモンを起動させて復帰です。
しかし、まさかpsコマンドで見えるプロセス名が「exe」とは思いませんでした。以前から
「なんでwineも動かしてないのにexeなんてプロセスが走ってるんだろう・・・?」
と疑問には思っていたんですよね。で、試しに
$ ps auwx | grep 18936 #18936はexeのプロセス番号
で確認したところ、

tako 18936 8.9 0.7 220972 5828 ? Ssl 13:37 3:40 pulseaudio -D

ってなってました。なんで「exe」なんて表記にしてんだろ・・・?
今でも時々PulseAudioがおかしくなりますが、だいぶ扱いが分かってきた気がします。以前にもこれと同じ状況に陥り、その時はどれがpulseaudioのプロセスか分からなかったので再ログインしたんですよねぇ。これでだいぶ対処がマシになりました。
以前より遅延も見られなくなったし、もうちょっとってところかな。プロセスがずっとデバイスを握りつづけてたら安定してるんだけど、デバイスを解放したり確保したり〜と頻繁に繰り返すとついていけなくなるって感じですね。
特に、aRtsとの相性がよろしくない。akodeplayが引数なしでpulseaudioを利用してくれるんならそれで片付くんだけどなぁ。aRtsは時代遅れだから使いたくないよ^^;
でもアップグレード直後に比べたらはるかに安定してるので、このまま使いつづけてみますかね。プロセスごとのボリューム調整は結構面白いし。記憶してくれないのが難点だけど。記憶させる方法もありそうだけどなぁ。
ま、ぼちぼち調べていきますか。Fedora8はまだ情報が少ないし。けど私のBlogはあんまり検索上位には入っていかないんだよなぁ。未だにエキブロのBlogの方が上位だし^^;
もちっと有用な情報出していかないと上位は難しい!?

デスクトップをみっくみくにしてみた

まぁ表題の通りであります。ちょっくら遊んでみました。ほんとはもうちょっと細かいディティールにもこだわりたかったんですがねぇ(苦笑
事の発端は、Velnirとのチャットだったり。ApricotってなWinのペルソナウェアではちゅねミクを動かしてる動画があって、それを送りつけたら「てめ〜もやれよ」とのご託宣を受けまして。
で、やろうとした(Linuxで)んですが、まぁ動くわけもなく。
最初Wineで動くかな〜ってチャレンジしたんですよ。そしたらなんと
「このバイナリは.NETだからMonoで動かせやゴルァ!」
って怒られまして。Apricotの配布サイトにはなるほど確かに.NETが必要と書いてあります。
えぇ、ダメだろうと、ダメだろうと思いましたよ?でもやらんわけにはいかん!ということで、monoで試してみました。
見事撃沈(ぉ 他にもSSPの初音ミクとかもあったんですが、ninix-ayaをビルドできなかったので断念。32bit環境ならできたかもなぁ。ターゲットアーキテクチャの変更ってできないんだろか? できるとは思うけどちょっくら分からなかったなぁ。
ということで、壁紙とスカイドームくらいしか設定できませんでした。Superkarambaのウィジェットはそのうち作ろう。
それよか先に、Linuxが安定動作するハードウェア環境を構築しないとね^^;

Fedora8にしてよかったこと、わるかったこと

相変わらず今日もXが堕ちまくる。ほんと、これの原因は特定したいなぁ。いい加減にしてくれよと。
さてさて、表題の通り、よかったことと悪かったことを考えてみましょう。
○よかったこと
・Compizがなかなかクール。BerylのときはF8キーがショートカットキーとして喰われてたけど、Compiz-fusionになってその設定がなくなったようなので半角カナを打てるようになって幸せ(ぇ
・64bitのみでよくなったパッケージが増えた。Flashもラッパーを噛ませることで64bit版Firefoxで動作可能。こいつはなかなか嬉しいお話。32bit版Firefoxを卒業しますた。
・IcedTeaが意外と使えること。JavaはJREの更新が割と頻繁で鬱陶しい。IcedTeaでAzureusが動いたので当面はこれで問題無し。Eclipse+CDTも動作するし、特別IcedTeaで問題ないかな。
◇わるかったこと
・PulseAudioに変更されたこと。別にALSAのdmixで困ってなかったのに、PulseAudioに強制変更されたおかげで設定をやり直す必要が多量に出てきた。デバイス問題にも悩まされたし、akodeplayコマンドがデフォルトでpolypを使用しないためaRtsを復活させる羽目になった。こいつがかなり不安定なので困っている。
・Skypeが使えなくなった。PulseAudioに対応していないため。ALSA経由とかだと使えたんだけど、ALSAデバイスを直接叩くためPulseAudioをサスペンドさせてSkypeを使うしかない。当然、その間はPulseAudio経由での音はでない。
・beagled-helperプロセスが大暴走。これはFedora8のせいじゃないかも。けどCPUリソースを90%近く持っていくのはやめてほしい。おかげでクロックが2GHzから下がってくれない。killすら無視するこいつはいったい何なの!?
ざっと思いつくのはこんなところかな。いいところとわるいところ、それぞれで相殺する感じだろうか? PulseAudioは悪い方に入れたけど、これは時間が経てば洗練されていくだろうから、いい方に入っていくと思われる。aRtsもESD経由で動作させたら安定に動作するみたい。ESDもaRtsも更新が止まって久しいものなあ。不安定だったのはALSA経由にしていたからみたい。そーいやaRtsってALSA経由だと不安定だったっけ・・・。
にしても、なんでakodeplayのデフォルトsinkもpolypにしなかったんだろう。そうしてくれてたらaRtsを起動する必要なかったんだがなぁ。システム通知をakodeplayにさせてたからなぁ。便利でよかったのに。これ以外に多数のフォーマットに対応した軽いコマンドって思いつかないのよなぁ。mplayerにさせるのは大仰な気がするし。
う〜んむ、akodeplay以外に、wavとoggに対応したコマンドラインベースのサウンドプレイヤーないかしら。aRtsはなんか好きになれないのよねぇ(苦笑)
ま、それよりなによりXが死ぬ原因を突き止めたいもんだ。こっちの方が深刻なんだよなぁ。大学のマシンは安定して動いてるから、ハード面だと思われます。だから余計に困ってるんだよなぁ・・・。
新マシン構築するにも金がない。はぁ、ハズレのハード構成だったなぁ・・・^^;

なんだこのむらは

今日はXが4回ほどお亡くなりになりました。何なんだ一体?
ふと、この不調はオンボードグラフィックをBIOSで無効にするのを忘れいてたからだろうかと思い、確認してみました。するときちんとBIOSで無効化していました。
う〜んむ、やっぱ相性・・・?
この不調がグラボのせいなのかM/Bのせいなのかははっきりさせたい所存。グラボとCompizの相性ということは考え憎いので、まぁこのM/Bとグラボの組み合わせがよろしくないということなのでしょうが・・・、この場合取れる選択肢は2つほど。
1つはグラボを交換する方法。1万円くらいで済みますかね。いっそのことオンボードグラフィックにするという手もあります。さして性能を欲していない今、オンボードグラフィックでも特に問題なく動きそうな気もします。
2つはM/Bを交換する方法。こちらも1万円くらいで済みます。換装の作業は面倒ですね。一旦全部外す必要がありますし。Linuxの方は交換後rescueディスクで起動してinitrdを再構築する必要あり。Windowsは下手すると入れ直しだなぁ。修復インストールで何とかなるとは思うのだけれど。もし再インストールならVista64bitだな(ぉ
しかし、今日も再起動した今の状態はすこぶる安定。一体何が不安定にさせているんだか・・・。
ところで、家のFedoraではUSBメモリが自動マウントできない状態となっております。なんかHALが文句たれるんですよねぇ。現れるメッセージでぐぐっても64bit版のopenSUSEしか引っかからないし。Fedoraでは出ていない症状なんだろうか?
SUSEの方では安定に動作していたときのパッケージをインストールしなおすことで回避してました。Fedoraもそうしたいところですが、F8の時点で既に発生している不具合なのでこれ以上戻しようがなかったり。F7のときにはマウントできていましたが、64bit以降どのタイミングでマウントできなくなったのか確認していないためどのverが安定に動作するか分からないんですよねぇ・・・。何気に不便だからどうにかしたいや。
にしても、Fedora8の情報はほっとんど出回ってないなぁ。検索の仕方は悪いかもしれないけど。そのうち色々と見つかるかなぁ? online-desktopとか面白そうだから知りたいのに。
やっぱここは人柱しかないか!? ま、色々試してみますかね^^

サウンドデバイスの権限問題解決法

先日ポストしたPulseAudioはなかなかよいかも知れないの記事に、/dev/snd/*等のデバイスの権限を強引に0777に置き換える方法を紹介しました。
するとjacopassさんがコメントにて解決法を紹介してくださいましたのでそちらを紹介します。この記事にてお礼とさせていただきます。
まず、/etc/security/console.perms.d/51-audio.permsというファイルを作成します。jacopassさんは50-default.permsファイルを編集する方法を紹介くださいましたが、こちらのファイルは手動で編集すべきファイルではないということで新規にファイルを作成することとします。ファイル名は先頭の数字が50より大きければ以降は任意です。ただし、拡張子は.permsにしてください。
編集する内容はコメントにいただいた通りです。以下の内容を保存してください。

<sound>=/dev/dsp* /dev/snd/* /dev/mixer
# permission definitions
<console> 0666 <sound> root

以上で完了です。先日の私の記事で書き換えた箇所を元に戻し、再起動すればOK。
記述の意味ですが、まず1行めはデバイスをグループ化しています。右側に書かれたデバイスはきちんと存在していなければなりません。
次の行は単なるコメントです。
最後の行がパーミッションに関わる内容で、<console>はコンソールからのログイン、ようはローカルからのログインを示します。
次のセクションでパーミッションを指定します。ログイン後、各ユーザにここで指定した権限が付与されます。
次のセクションがデバイスグループの指定です。先ほど作成したグループの<sound>を指定しています。
そして最後のセクションは、ユーザがログインした後にどのユーザに権限を戻すかを示しています。ここではrootユーザに戻しています。
一般にサウンドやビデオデバイスはこの方法かあるいは先日紹介した方法でパーミッションの設定を行わないといけません。その場でデバイスのパーミッションを変更しても、再起動すると元に戻ってしまいます。
そういえばKVMデバイスも元に戻っちゃってたな・・・。アレも同じように設定したらいいのか。
先日の方法と違い、今回の手法ではデバイスごとに個別に設定を行えるのでパッケージ更新などでファイルが書き換えられてしまう心配がほぼありません。逆に言えばその設定が不要になったときはちゃんと自分で消さないといけないということですが^^;
何はともあれ解決法が見つかってなにより。これでおおよそはうまく動いてくれるかな〜?

丸一日課題と戦っておりました

今日は会社の課題を提出しようと朝から頑張っておりました。
今までは特に合格ラインというモノはなく、期日までに提出すれば良かったのですが、あまりに点数が悪かったのか、合格ラインが70点に定められました^^;
で、私はというと、今までそのラインに到達したことなかったんですよねぇ・・・>< ということで今日は気合入れてがんばったのですが・・・、朝の一発目は撃沈。というか過去最低タイでしたOrz
これじゃいかんということでちょっくら勉強開始。その後後輩の相談を聞いたり教授から次にやって欲しいことの話を受けたりと大忙し。つーかなんだこのタスクスタックのたまり方は!
そんなこんなで2回目にチャレンジしたのが16時くらい? 既に集中力も底をつきかけており、分からない問題はてきとーに答えてしまう始末Orz
にもかかわらずはじき出した点数は今までと変わらない点数ってどーゆーことよ? まぁ勘で書いた問題がかなり当たっていたからと言うのはあるけど、なんかやるせない気分に。
このままではほんと終われないんじゃないかと思いつつ3度目の挑戦。時刻は既に18時になろうかとしていました。
結果、なんとかボーダー越え。問題に恵まれたこともありましたが、勉強したかいもちょっとはありました。電気系の問題は久しく触れていないので、どうしてもパッとは思い出せないんですよねぇ。問題の難易度的にはさほど難しくないハズなんですけど^^;
問題はランダムで変わるし、1問5分以内に解けと言うしばりはあるしで結構きつい。来月も同じように苦しまないといけないのかーと思うと気が滅入るなぁ・・・。勉強不足な自分がいけないのだけれど、早解きはやっぱり得意じゃないや。時間さえ貰えたらなんとか頑張るんだけどなぁ。
今日はこの課題で丸一日を潰してしまいました・・・。質問に来た後輩を無碍に帰してしまったよw 明日からの学会帰ってきたらちゃんと相手するから赦しておくれ。
さ、明日から熊本だ。一気に寒くなったからなぁ。熊本も寒いのだろうか? 発表練習、またも不十分なんだよなぁ。今から風呂でちょっと練習してくるか・・・。
それでは、行ってくるであります!

PulseAudioなかなかよいかも知れない

さて、本日ようやく稼働し始めたFedora8ですが、PulseAudioには結構満足してます。Vistaにも導入されたらしいのですが、アプリケーションごとにボリューム調整が可能となっています。
ただ、正直私はこれの意味が分かってなかったんですよね^^; 各アプリケーションのボリュームが調節できるって、大抵のアプリケーションには音量調節機能はついてるじゃねーかと。マスターボリュームを調節してしまうステキ仕様のアプリもまれにありますが、最近ではそれもまずありません。
じゃー各アプリケーションのボリューム調整ができるってどーゆーことよ? って、実際見てみるとなるほど各アプリのボリューム調整ができる仕様となってました。
音を鳴らすアプリケーションと言えばマルチメディア系で、そいつらは基本的にボリューム調整できるだろと考えてましたが、よくよく考えればシステムサウンドもそうだし、Skypeなどのキャプチャソフトもそうです。結構ボリューム調整ができないか、あるいはマスターのボリュームを弄ってしまうアプリもありましたね。こいつらのボリューム設定も個別にできるようになったのは面白いです。
使いどころとしては、ちょっくらやかましいチャットクライアントのボリュームを下げておくとか、複数のサウンドデバイスを持ってるならシステムサウンドとマルチメディア系を振り分けちゃうとか。
複数デバイスを持っているときに好きなアプリケーションを好きな方のデバイスに割り振れるのは面白いと思うんですよ。音楽とかはヘッドフォンで聴いてるけど、システムサウンドはスピーカから出す、みたいなことができるというわけで。
これでヘッドフォンを繋いだと思っていたのにきちんと繋がっていなくてスピーカからエロゲサウンドが大音量で流れる心配もなくなるね!
と、いうことでPulseAudioを利用している状況をちょろっと紹介。

こんな感じで、サウンドを利用しているアプリケーションのボリュームを個別に指定できます。ついでにPulseAudioはネットワーク対応ですので、他のマシンのアプリケーションのサウンドを鳴らすことも可能。あるいは他のマシンに鳴らしてもらうことも可能です。なかなか面白そうだと思ったのは、マイクなどでキャプチャしたサウンドをマルチキャストして接続しているPulseAudioクライアントに一斉送信できる点です。こいつ使ったら特別なソフトなくして音声チャットできるじゃねーか!と。いやまぁルータの設定とかあるし、遅延とかえげつなさそうだけど、機能としては面白そうだわ。
また、仮想OSには向いてると思う。ゲストが持つ仮想デバイスはそりゃ品質よろしくないだろうし。いやまぁ、仮想OSにそんなものを求めるのはどうかという話はあるのだけれど^^;
ただ、Fedora8が出たばかりだと思いたいですが、先刻のポストに書いたように/dev/snd/*と/dev/mixerデバイスのパーミッションがおかしいです。あるいはPulseAudioの設定がおかしいです。
サウンドデバイスはudevによって管理されており、設定を見るとroot権限でのみ使用可能(0644)となっています。pulseaudioコマンド自体はsuidが有効になっているんですが、内部で即root権限からpulse-rt権限へ降格しているらしいです。
そのせいか、pulseaudio実行後、デバイス検知は行えますが設定が行えていません。Fedora8を新規でインストールしたらそのような不具合はでないのかもしれませんが、まだ情報が少ないため様子見ではあります。
が、毎度毎度起動する度に手動でchmodするのも面倒なので、しばらくの間は該当デバイスのパーミッションを0777にしておくことに。よい子は真似しちゃダメだよ!
設定方法は、/etc/udev/rules.d/40-alsa.rulesファイルを開き、controlCからmixerの部分まで各行の末尾に
,MODE=”0777″
を追記したらOKです。これでudevが作成する該当デバイスのパーミッションが0777になります。まぁこのファイルは本来手動で書き換えてはいけないファイルであり、udevパッケージが更新されたら書き換えられる可能性が大です。まぁその頃までには解決法が分かっている・・・だろうと信じたい。Fedora7から8へアップグレードしたという記事はいくつか見つけましたが、あんまり「その後」を書いたサイトを見ていないですからねぇ。出てから間がないので仕方ありませんが。
とりあえずこれで問題なくサウンドが有効となりました。PulseAudio共々もう少し調べてやる必要がありそうですね。ゲストOSのサウンドをネットワーク経由で受けるというのも試してみよう。
ま、それもこれも今月の20日を過ぎないことには暇なんてできないんだけどね!Orz

Fedora7->Fedora8

え〜、苦労しました>挨拶
私が学会で仙台に行っている間にFedora8がリリースされました。絶対遅れるだろうと思ってたんですけれどねぇ。予想に反して(こら)予定どおりリリースされたようです。
そうとなればインストールしない訳には参りません。さっそくfedora-releaseパッケージをFedora8のサーバからDL&インストールし、yum updateを実行。
が、失敗。というか、$releaseverが7のまま。これじゃ意味がない。今までだとfedora-releaseパッケージを更新するだけでいけてたのに・・・と不思議に思いながらも、面倒なので/etc/yum.repos.d/fedora.repoを直接編集し、強引に8のリポジトリを見にいくように修正。
で、再度yumを実行。今度はきちんと8のリポジトリを参照し、パッケージのヘッダをDLし始めました。
・・・長い。こりゃ久々に1000単位の更新になりそうやな〜と身構えていると、案の定1300ちょっとのパッケージが。
ただ、意外なことに依存性の欠如による更新処理の続行不可ということは起きませんでした。大抵yumでアップグレードをしようとすると出るんですけれどね。珍しいな〜と思いましたね。
で、1.4GBのパッケージ群をちまちまDLしまして、いざ更新作業・・・と思いきや、なんとここにきてエラーがOrz
依存性チェック、トランザクションテストの実行後、解決不能な依存性があるとか。なんでやねんと思いつつ、表示された依存関係にあるパッケージとメッセージをぐぐる。
すると、あっけなくヒット。どうもFedora7から8へyumでアップグレードする場合に発生するエラーらしく、解決策も示してありました。
というか、さらにぐぐればUpgrading Fedora Using Yumにご丁寧にyumでのアップグレード方法が書いてありました。もっと早くから知っておきたかったぜ・・・。
ちょうどいいサイトが見つかったことですし、ここの通りに実行しようってことで実行したところ、思いも寄らぬエラーが!
なんと、インストール作業が始まった直後、メモリ確保に失敗してセグメンテーション違反でアボート。思わず
「ねーよwww」
と叫んでしまいました(ぉ いや、確かに私はごちゃごちゃと色々アプリケーションは立ち上げてますし、空きメモリは多くないです。ブラウザも立ち上げてましたし(Firefoxは起動時だいたい100MB喰っている)、yum実行中は実メモリ730MB/1GB、スワップは350MB/512MBの使用状況でした。
で、yumが落ちたあと、実メモリが300MB、スワップが120MB程度空きました。てめーどんだけ喰ってたんだと。
今までもyumでアップグレードしたことはありますし、2000パッケージくらいの更新も経験した事があります。当時は実メモリが512MBだったはずです。いくらなんでも喰いすぎじゃねーかと。
で、困ったことに中途半端にインストール処理が実行されたせいで古いパッケージと新しいパッケージが混在し、yumが失敗するようになってしまいました。インストールしようとしても「既にインストールされています」とか出ちゃう訳ですな。
仕方ないので、該当のパッケージを手動でrpm –forceでインストールする事に。
これが地味でしんどい作業になりましたね・・・。パッケージ数が多いため、yumの1度の実行に5分程度掛かります(依存性解決の計算が長い)。でインストールプロセスを実行し、失敗したパッケージを手動で上書き。手動なため依存性を地道に解決する必要があり、これまた依存性を調べるのに時間が多少掛かります。
そんなこんなで、地味な作業に時間を奪われ、仙台から帰ってきた日はほとんどパッケージを更新できないまま終えざるを得ませんでした。次の日は朝から結婚式でしたしね。2時まで頑張りましたが諦めて寝ることに。
そして結婚式から帰ってきた昨日、再び更新処理に取りかかることに。前日の続きで地味な作業をこつこつ。
無事混在していたパッケージの更新が終わり、yumが実行可能に。ただ、yumは実行可能となりましたが、8がリリースされた直後ということで修正パッケージが既に発生。それをDLする羽目に。
それくらいならまぁいいかと思ってたのですが、運悪く海外のサーバを見に行ったため遅い。100KB/s出ないんだから洒落にならない。ミラーを変更してみてもどうやら更新が出たばかりなのか見つからないとかでyum途中終了。こうなると1000近い依存性チェックが発生するため仕方なくDLを待つことに。
たった10個の追加パッケージをDLするのに15分程度掛かってしまいました。その間メモリ不足になってはいけないとブラウザも起動しませんでしたから退屈でした^^;
で、DLも終えてインストールプロセス実行。無事実行されてるな、そう思っているとselinux-policy-targetedパッケージの更新で処理中断。どうもポリシーの書き換えを行っている模様。
ただ、長い。長すぎる。確かにポリシーの書き換え処理は長いけれど、これは長すぎるだろう。だって2時間待っても終わらないんだもん。
あまりに不自然ということで、yumプロセスを^C+cで終了。再度実行すると、また出ましたパッケージ混在。
鬱陶しかったのでselinux-policyパッケージを削除。どうせselinuxはPermissiveモードでしか動作させてないし、個人使用しかしないOSならさほど必要ないだろうと。
で、削除して再度プロセス続行。selinuxのポリシー書き換えまでに1000近くの更新は終わっていたのが幸いし、残りは100個ちょっと。ただ、ここからがまた地味に大変でした。
というのも、混在していたパッケージを手動上書きしていたわけですが、なんか芋づる式に混在パッケージが増えてくる。ほんと地味な作業で大変でした。モチベーションも下がるし。
で、ようやく100個を切ろうかとしたとき、再び悪夢が。メモリ確保に失敗s(ry
正直、まさかと思いましたね。100個程度の更新なら割とよくやってたため、その時はブラウザ起動してたんですよね。油断してました・・・。まさか再びメモリ不足に陥るとは。
噂によるとyumの実行速度が向上したようですが、メモリの使用量は反比例してめがっさ増えたんじゃないだろうか。ほんと無茶だぞこのメモリ使用量。1GBで足りなくなるとかありえねぇ。
で、こうなるとやっぱり手動で上書きの処理が発生する訳で・・・。そんなこんなを繰り返し、なんとか更新処理が終わったのが夜中の1時すぎ。更新処理だけで丸々2日費やしてしまいましたOrz これならLiveCDでも作ってネットワークインストールでちゃんと更新シーケンスを実行した方が早かった気がしてきたよ。負けた気分。
続いて、Fedora8で追加された基本パッケージのインストール。Fedora8ではサウンドサーバがPulseAudioを標準としていますのでそれのインストール。これはまぁ特に問題なく終了。Fedora7ではうまく設定できなかったのでどうなるかな〜と思いつつwkwkしながら再起動。
ブート後、グラフィカルブート失敗。まぁ、カーネルを更新したけれどfreshrpmsがまだ8に対応していないようでドライバを更新していなかったので予想通り。ただ、予想ガイだったのはFedora7のカーネル用のモジュールをdkmsにより現在のカーネルに適用してくれたこと。起動が少々遅くはなりましたが、ドライバはきちんと当たった状態でX(GDM)が起動してくれました。これは嬉しい誤算でしたね。
で、無事起動したはよかったのですが、ここでまたトラブル発生。なんと、音が一切でない。いやー、Fedora7のときはPulseAudioがうまく設定できなかったからある程度それも予想はしていたのですが、まさか音が一切鳴らないし、ALSAを利用するようにしておいたアプリケーションが全て鳴らないというのは驚きました。dmix無効にしなくてもいいじゃねぇかよと。
ただ、ひょっとしてドライバに不具合があるのかもしれないと思い、サウンドカードの検出を実行。テストサウンドを鳴らしてみると、なんとこれが鳴るんですね。鳴ってるじゃねーかよと。
これはますます困る。テストサウンドが鳴るということは十中八九こちらの設定がまずいということ。ただ、調べようにも2時を回っていたのでダウン。次の日へ持ち越しました。
そして今日、サウンドの設定に取りかかりました。まず確認すべきは、ほんとにサウンドは鳴らないのかどうか。一旦rootユーザでログインし、試してみることに。
するとどうだろう。rootユーザはふっつーに音鳴ってるんですね。意味わかんねぇ。
続いて一般ユーザでpulseaudioを起動。失敗。正確には、pulseaudioがALSAデバイスは検出しているけど、デバイスにアクセスで来ていないらしい。
となると、ユーザの方に問題があるということになります。つーわけで、新規にユーザを作成し、そちらはpulseaudioが正しく起動するのかをチェック。
するとやっぱり失敗。ということで、一般ユーザに対する設定が足りていないと目星をつけ、エラーメッセージをぐぐって海外の掲示板を漁り、一般ユーザに権限を与える処理を行っていそうな解決策を提示しているサイトをチェック。
すると1件発見。どうやら/dev/snd/以下のデバイスと/dev/mixerデバイスに権限を与えればいいらしい。
試しにchmod 777を実行すると、あっけなくpulseaudio起動。ただ、起動しても、Fedora7の頃は音飛びが発生していたのでまだ油断できません。適当にいくつかの音を再生してみました。
するとどうでしょう(劇的ビフォーアフター風)! 何の問題もなく音が再生されているではありませんか!
これでなんとか各設定が終了しました。まだどこかで問題は発生しそうでなりませんが、なんとか使う分には問題なさそうです。Fedora8になってアイコンなどのテーマが刷新され、柔らかい雰囲気になっています。壁紙などもおとなしいですね。
ふむ。Fedora8になってx86_64パッケージも充実してきて、i386パッケージはだいぶ減ってきたみたいだし、新規で入れ直したらもっとトラブルは少ないだろうな。
あ、調べたところ、yumのアップグレードで発生するエラー(一番最初に出くわしたやつ)は64bit版のみで発生するようです。ま、解決法が書いてあったのでこれは知れた問題ですけれどね。まだ64bit版は使いどころが難しいということでしょうかね。ぼちぼち普及して来るとは思います。早いところFlashのライブラリが64bitに対応してくれないかねぇ。これが32bitだからFirefoxも64bitにできねぇよ。ニコニコできなくなるもん(ぇ
さて、今回の奮闘記はこんな感じです。疲れはしましたが、正直Fedoraの更新はこれくらいやってくれないとつまらないと心のどこかで思っていたりもするw やっぱ銅鑼ブルでも起こらないと調べたりしないからなぁ。
ほんとは時間ないんだけどね^^; 明日明後日の2日間で熊本の学会スライド完成させないといけないし、明日はTAで3時間弱持ってかれるし・・・。
あ、ほんとにやばいかも。ここを越えたら・・・、あぁ、会社の課題提出だOrz 70点以上がボーダーになっちゃったからなぁ・・・。これを帰ってきて速攻片付けないといけない。
HAHAHA・・・。20日過ぎるまでは休む暇が与えられないな・・・。チックショーーー!!!Orz