openSUSE10.3からopenSUSE11.0へアップグレード #1

openSUSE10.2から同10.3へのアップグレードでも多少の問題はあったにせよ、まぁなんとか稼動状態からアップグレードはできた。

現状、openSUSE10.3で困っている事はないし、いわゆるLinux desktopもほとんど使用しない。なので別にアップグレードしなければならない必然性は無い。

しかし、いずれセキュリティアップデートが提供されなくなる事を考えるといつかはアップグレードした方がいい時が来る。セキュリティに不安があるよりは不安がない方がいいに決まっている。いくら攻撃対象がWindowsよりは少ないであろうLinuxであってもセキュリティホールが皆無ではないのである。

そこで10.3へアップグレードした時の手法で、バージョンアップグレードを試みるが…。自動では解消できない依存性があまりにも多い。手動で解決しようにも、あちらを立てるとこちらが立たなくなりどうにもならない。

実は、YaSTの「システムアップグレード」、10.3では消えて無くなっている。これは暗にそんな事はしてくれるな、という意味か。そしてそれを無くしたからこそ、旧バージョンからのアップグレードでたくさんの解消できない依存性を伴っているのか(後日談:Factory Updateがそれに該当するようだ)。

いちいち新規インストールした方が確実であるのは理解できるが、インストールマニアじゃないんだし、面倒くさくってやってられない、そんな事。

で、何時間か格闘の末、依存問題パズルを解く事に飽きてしまった。他に手段はないかとwebを検索してみる。まさしくこれだ!というページが見つかる。

openSUSE 10.3 稼働中のシステムを 11.0 へアップグレード

アップグレード後、設定ファイルが消失するものが2つ程あるらしいが、見る限りは致命的ではなさそうだ。これで行ってみよう。

しかし、zypperの遅い事遅い事。aptなんかと比べるとHDD容量を使用しないらしいのだが、その分ふんだんにメモリを消費するようで、結果swapを大量に消費。そしてzypper.logのサイズもみるみる膨れ上がり…。1時間半待っても終わらず、終わるのを待つのをやめた…。

3時間経っても終わっておらず、どんだけ遅いんだよ、と中止したくなるが、これまた遅かったzmdなんかは寝て待った事もあったので、なんとなしにインストール済みパッケージ数でも調べてみる。1179。多いねぇ…。考えも無しにインストールした結果なのか…。ある意味自分も悪い。不必要なパッケージはインストールしない、あるいは削っていくべきだと痛感。

240分(4時間)経過したところで痺れを切らしてしまい、中断。勿体ない事をしたかも知れない!? zypp.dbファイルやRPMデータベースを最適化?して再スタート(詳細はSDB:Speed up Package Manager Stack)。これがどれだけ時間を短縮できるかどうかは疑問ではあるが…。

再開後、メモリ使用量は同じようにぐんぐん上昇し、ログファイルも同じように肥大していく。ファイルのフラグメントを解消した程度ではやはり効果の程は薄い…。で、ペンディングを意味するのだろうか、Pendの後の数字も先程と同様にどんどんと増えて行く。こりゃあまた数時間はかかりそうだ…。

再スタートから3時間経過。Pend 25308 / Cmpl 0 / Prun 0 / Defr 0 / Invl 891。Prunの意味が今一つ推測できないが、PendはPending、CmplはComplete、DefrはDefer、InvlはInvalidあたりか? 先程と似たような状況でひとっつもコンプリートできていない様子。流石にメモリにがSDRAM、Mobile Athlon 1400+(1.2GHz)という何世代も前のシステムでは相当に辛いのだろうか。

余談になるが、Mobile Athlon 1400+のTDPは35W。であれば、Atom N230(1.6GHz)のTDP4Wのがいいよなぁ…。ただでさえ、電気代等色々なものの値上がりが止まらない昨今。エコの観点でもそれに越した事はないなぁ…。Intel純正マザーボードなら8000円強。プラス必要なのはDDR2メモリ。これも最近は安い。問題はアーキテクチャが変わるから新規にインストールしないとならない事か…。あぁ、LANもオンボードの1個しか無いから追加のLANカードが必要か。余ってるのがあるからそれはなんとかなりそうだ。いずれそうしてみるか…。

話を戻そう。ログファイル(zypper.log)を見る限りは依存性の問題についてYaSTで何とかしようとした時と同様の問題が発生しているように見える。依然としてPendは増え続け、Cmplは0のまま。システムを稼働したままで処理が継続するのは(ルータやいくつかのサーバ機能として稼働させているLinux Boxでは)一つの利点ではあるが、数時間かかっても終わらないのであれば、起動ディスクを作ってそこからアップグレードした方が時間的コストは低かったのではないか? そんな事が頭をよぎるが今更言っても仕方ない。今はひとえにzypperの処理が終わるのを待つしかない…。

少々惰眠をむさぼり、ぼーっとした頭で確認に向かうと、8時間経過して「out of memory」とかで終わってる…。どんだけふざけてんだよ…。

2008-07-06 20:22:32 <1> hoge(31758) [zypper] zypper.cc(main):1663 Hi, me zypper 0.8.25 built Oct 10 2007 15:58:36

2008-07-07 04:19:08 <5> hoge(31758) [zypp] Exception.cc(log):119 zypper.cc(safe_one_command):1540 CAUGHT:   sqlite3x_reader.cpp(read):71: out of memory
2008-07-07 04:19:09 <1> hoge(31758) [zypp] PathInfo.cc(_Log_Result):295 recursive_rmdir /var/tmp/zypp.8vAZG9
2008-07-07 04:19:09 <0> hoge(31758) [zypp] TmpPath.cc(~Impl):78 TmpPath cleaned up /var/tmp/zypp.8vAZG9{d 0700 0/0}

微妙に増えたり減ったりもたまにあったようだが、結果はCmpl 0。

2008-07-07 04:19:06 <0> hoge(31758) [zypp] Resolver.cc(resolveDependencies):1057 Pend 45959 / Cmpl 0 / Prun 0 / Defr 0 / Invl 2598

sqliteを使ってるみたいだが、適当にインストールしたとはいえ、正規のパッケージたち。それすら扱えず、out of memory とか言ってるようじゃパッケージマネージャにならないんじゃないのかねぇ…。

しかしこれだけ依存性が解決できないとなると、起動メディアからのアップグレードも恐ろしい事が発生しそうな気がするのだが…。

メジャーバージョンアップもいいけど、大きな変更がないなら簡単にアップグレードできるようにしておいて欲しいもんだな…。

他のパッケージ管理ツールでうまく行くとも思えなかったが、yumやsmartも試してみるかと、まずはsmartをインストール。

そしてsmartでアップデートを実行したら結構すんなりと進行している! この差はいったい…。と思ったがmailmanが入った所で死亡…。ちょっと、やばいんじゃねえの…。というかmailmanまで入ってたのか…。ほぼ全パッケージを考えもなしに突っ込んだのかねぇ…。覚えてないぞ…。

とヒヤリとする場面もあったが、雲泥の差、あっけなくアップグレード処理終了! しかしいつもgrubではまるので確認…。………。設定、古いまま…。危うくリブートしてはまるところだった…。そういう事でgrubの設定を書き換え終了。いざ再起動! (注:他の環境ではgrubの設定も書き換えされているのは確認済みなので、このPCの設定で何かがおかしいのだと思われる)

ほっ、大きな問題は無し。アップグレード後の懸念事項である各パッケージがバージョンアップした事による挙動の違いだが、何点かあった。

  1. postfixが開始直後にdead。
    → /etc/services に smtps の(エイリアスの)記述がない事が原因。元々あったものが消えたのか、どうなのか深く原因は追究していないが、smtpsを追加。
  2. cactiが処理待ちに。
    → バージョンアップ用スクリプトを実行する。更にcactiでphpのsocketが有効になっていない、と。php-socketが入っていなかったのでsmartでインストール。だが、肝心のグラフが描画されない。perlモジュール絡みくさい。未解決。
  3. Xをvncで接続した際にマウスカーソルが表示されない。
    未解決。

まだ解決できていない点が残っているが、概ね問題は無く順調に稼働している。

しかし、YaSTやzypperといったSUSEでは純正?系(と思われる)パッケージ管理ツールでは駄目でsmartですんなりいくとはちょっと考えにくかった。作業時間が無駄になったなぁ…。そのsmartも慣れないとやはり馴染めない部分もあるので、パッケージ管理ツール選びも難儀なものだ。

で、結果1283個のパッケージと増えていた…。

シェアする

  • このエントリーをはてなブックマークに追加

フォローする