2011/12/12

FreeBSD9.0-RELEASE前に練習。実運用中のマシンでやっちゃ駄目よ?

ここで使うマシンは

CPU: AMD Phenom(tm) 8450e Triple-Core Processor (2099.93-MHz K8-class CPU)

という、今となっては古すぎる部類の奴で、アーキテクチャはamd64(64bit)です。

2012/01/05
9.0-RELEASE出ました。同じ手順でインストール出きる事を確認しました。

ずっとcvsupコマンドでやってきてるので今回も。supfileに書くtagはこれでよいみたい。

*default release=cvs tag=RELENG_9_0

freebsd-updateコマンドでもいいんでしょうけど、わたしはうまくいった事が数えるほどしかないので。

いつも使っている方法でportsツリーも新しくしておきましょう。わたしはこれもcvsupを使ってます。

UPDATINGには特に目立ったものはなさそうなので、Makefileに書かれている手順でコンパイルしていきます。

-j オプションで処理を多重にしてくれるそうなので、4多重=-j4 を指定。

make -j4 buildworld

この -j4 は他のターゲットの時も指定してくださいな。このmakeが通ればツール回りが出来たのはずなので、次はカーネルのビルド。

…お、コンパイルオプションに

  -DLLVM_ON_UNIX -DLLVM_ON_FREEBSD

とか出てる。コンパイラ変わったからって理解でいいのかしらん？

特にコンフィグレーションいじっていないならこれでOK。要はGENERICのコンフィグ使うぜって事。

make -j4 buildkernel

コンフィグをいじるのは大概無駄なデバイス定義を削ってメモリの確保をやったり必要な非標準機能に火を入れたり起動時に必ず有効でなければならないモジュールを指定したいような場合。 今時ならほとんどの場合カーネルモジュールの形でカーネルから分離されているし、モジュールのロードもあとから指定できる。よほどのことがなければいじることもないと思う。

make installkernelの前にサービス関連は停止しておきましょう。

データベースを動かしているならデータのバックアップを行ってから停止します。 Jailを動かしている場合も同じく。

今回試しに停止せずにmergemasterまでやってリブートしたところ、JailにいたPostgreSQLが立ち上がらず、ブートシーケンスがぴたっと止まってしまい、CTRL+Cで殺さないと先に進みませんでした。

あらかじめ、可能な限りサービスを止め、/etc/rc.conf のenabled=“NO”への書き換えをやっておきましょう。

mergemaster やりますからねぇ。しくじった場合の保険です。

とうとう覚悟を決める時間です。これでカーネルモジュールを置き換えします。

make -j4 installkernel

本来の手順だとシングルモードで再起動なんですけどね。 実は遠隔地にあるマシンのアップデートを想定しての練習でもあったりするので、リブートしないで続けて見ます。

はいはい、おっかないmergemasterの時間です。

mergemaster -p

まだこれは簡単なほうですよ。 基本は i でインストール(上書き)するだけですが、自分で更新した設定ファイルは m でマージします。

このターゲットをmakeすることで、ユーザランドも9.0-RC3になります。

make -j4 installworld

FreeBSD9.0ではもう使用しない設定ファイル等をバックアップしてから消してくれます。

make -j4 delete-old

今度は -p が付かないmergemasterの実行です。/etc などの下にあるファイルの更新です。対象の量も多いし、単調な作業になるのでおそらく手順的に一番誤りの発生するところでしょう。

mergemaster

基本は -p が付いていた mergemasterとおなじ。 以下なんかは気をつけないと泣きを見ます。sshd_configなんかはやっちまったら最後、現地に行かないとどうしようもありません。

• passwd
• hosts
• mailer.conf
• shells
• sshd_config
• sysctl.conf
• ttys
• named.conf

どきどきの瞬間。リブートできたらいいね。 これでリブートしなければコンソールへ直行して作業しなきゃなりません。どきどきして待ちましょう。

再起動が出来て、うまく更新がいっていれば

FreeBSD 9.0-RC3 (GENERIC) #9: Sun Dec 11 07:18:45 JST 2011

が表示されているかと思います。

これはまだ実行しないほうがよろしいかと。 というのは、古いライブラリの回復手段を失ってしまった場合、動かなくなるアプリ、サービスが出てきてしまうためです。 まぁ、そもそも9.0で使えないライブラリの場合はどうしようもなくなりますが。

止めていたサービスやJailの回復を行います。

わたしは ezjail を使っているので、ezjail-adminで各Jailのバイナリを更新します。

ezjail-admin update -i

-iオプションは、ビルド済みのバイナリをJailへ適用する指定です。 既にホストのアップグレードのために必要なバイナリはビルドされているので、再コンパイルをしないでそのまま利用させるということですね。

disabled=“NO” を YES に戻すだけですね。

念のため、portsで導入しているアプリの再コンパイルをやっておきます。

ほとんどの場合は問題ないと思うけど、7.xRELEASEの頃から使ってます的なアプリがあるならこれを機会に再コンパイルやっときましょう。 大量にそういうのがある、コンパイルつらい、というなら /usr/ports/misc/compat7x などの互換性維持のためのライブラリを導入してみればよいかと。

カーネルパラメタで、8.2にはあったけど9.0-RC3には存在しないものがあるようです。 kern.ipc.semmap はPostgreSQLのインストールに当たって変更する必要があったパラメタなんですが、少なくとも 9.0-RC3にはないようです。

amanda# uname -a
FreeBSD amanda.hogehoge.jp 9.0-RC3 FreeBSD 9.0-RC3 #9: Sun Dec 11 07:18:45 JST 2011     k@amanda.hogehoge.jp:/usr/obj/usr/src/sys/GENERIC  amd64
amanda# sysctl kern.ipc
kern.ipc.maxsockbuf: 2097152
kern.ipc.sockbuf_waste_factor: 8
kern.ipc.somaxconn: 128
kern.ipc.max_linkhdr: 16
kern.ipc.max_protohdr: 60
kern.ipc.max_hdr: 76
kern.ipc.max_datalen: 92
kern.ipc.nmbjumbo16: 3200
kern.ipc.nmbjumbo9: 6400
kern.ipc.nmbjumbop: 12800
kern.ipc.nmbclusters: 25600
kern.ipc.piperesizeallowed: 1
kern.ipc.piperesizefail: 0
kern.ipc.pipeallocfail: 0
kern.ipc.pipefragretry: 0
kern.ipc.pipekva: 655360
kern.ipc.maxpipekva: 129699840
kern.ipc.msgseg: 2048
kern.ipc.msgssz: 8
kern.ipc.msgtql: 40
kern.ipc.msgmnb: 2048
kern.ipc.msgmni: 40
kern.ipc.msgmax: 16384
kern.ipc.semaem: 16384
kern.ipc.semvmx: 32767
kern.ipc.semusz: 632
kern.ipc.semume: 50
kern.ipc.semopm: 100
kern.ipc.semmsl: 340
kern.ipc.semmnu: 256
kern.ipc.semmns: 512
kern.ipc.semmni: 256
kern.ipc.shm_allow_removed: 0
kern.ipc.shm_use_phys: 0
kern.ipc.shmall: 32768
kern.ipc.shmseg: 128
kern.ipc.shmmni: 192
kern.ipc.shmmin: 1
kern.ipc.shmmax: 134217728
kern.ipc.maxsockets: 25600
kern.ipc.numopensockets: 147
kern.ipc.nsfbufsused: 0
kern.ipc.nsfbufspeak: 0
kern.ipc.nsfbufs: 0
amanda#

また、portupgrade コマンドを使っている場合、注意がいるかもしれません。 私のときは、ruby18-dbd との依存関係が解決できないようで、makeのコマンドラインに -DFORCE_PKG_REGISTER をつけて手動で導入しました。ほかにも、ruby-dbdのバージョン等によってうまく更新できないことがあるかもしれません。

そういう時はばっさり入れ直しですねぇ。

あ、ほかには

[Updating the portsdb <format:dbm_hash> in /usr/ports ... - 20903 port entries found .........1000.........2000.........3000.........4000.........5000.........6000.........7000.........8000.........9000.........10000.........11000.........12000.........13000.........14000.........15000.........16000.........17000.........18000.........19000.........20000.............HASH: Out of overflow pages. Increase page size error] Remove and try again.
[Updating the portsdb <format:dbm_hash> in /usr/ports ... - 20903 port entries found .........1000.........2000.........3000.........4000.........5000.........6000.........7000.........8000.........9000.........10000.........11000.........12000.........13000.........14000.........15000.........16000.........17000.........18000.........19000.........20000.............HASH: Out of overflow pages. Increase page size error] Remove and try again.

こんなのが延々繰り返し表示で進まない。こんなときはこちらで説明している方法などをどうぞ。http://forums.freebsd.org/archive/index.php/t-8882.html

amanda#  clang -v
FreeBSD clang version 3.0 (branches/release_30 142614) 20111021
Target: x86_64-unknown-freebsd9.0
Thread model: posix
amanda#

もしportsあたりで入れたようなものがあれば消しておきましょう。

デバイス名変わってるから、fstabとか修正しなよー、というので見てみると、あー、ほんとだー。

amanda# cd /dev
amanda# ll
total 2
crw-r--r--  1 root  wheel       0,  35 12月 11 09:12 acpi
lrwxr-xr-x  1 root  wheel            4 12月 11 09:12 ad4 -> ada0
lrwxr-xr-x  1 root  wheel            6 12月 11 09:12 ad4s1 -> ada0s1
lrwxr-xr-x  1 root  wheel            7 12月 11 09:12 ad4s1a -> ada0s1a
lrwxr-xr-x  1 root  wheel            7 12月 11 09:12 ad4s1b -> ada0s1b
lrwxr-xr-x  1 root  wheel            7 12月 11 09:12 ad4s1d -> ada0s1d
lrwxr-xr-x  1 root  wheel            7 12月 11 09:12 ad4s1e -> ada0s1e
lrwxr-xr-x  1 root  wheel            7 12月 11 09:12 ad4s1f -> ada0s1f
lrwxr-xr-x  1 root  wheel            7 12月 11 09:12 ad4s1g -> ada0s1g
lrwxr-xr-x  1 root  wheel            4 12月 11 09:12 ad6 -> ada1
lrwxr-xr-x  1 root  wheel            6 12月 11 09:12 ad6s1 -> ada1s1
lrwxr-xr-x  1 root  wheel            7 12月 11 09:12 ad6s1d -> ada1s1d
lrwxr-xr-x  1 root  wheel            7 12月 11 09:12 ad6s1e -> ada1s1e
crw-r-----  1 root  operator    0,  93 12月 11 09:12 ada0
crw-r-----  1 root  operator    0,  95 12月 11 09:12 ada0s1
crw-r-----  1 root  operator    0, 100 12月 11 18:12 ada0s1a
crw-r-----  1 root  operator    0, 102 12月 11 09:12 ada0s1b
crw-r-----  1 root  operator    0, 104 12月 11 18:12 ada0s1d
crw-r-----  1 root  operator    0, 106 12月 11 18:12 ada0s1e
crw-r-----  1 root  operator    0, 108 12月 11 18:12 ada0s1f
crw-r-----  1 root  operator    0, 110 12月 11 18:12 ada0s1g
crw-r-----  1 root  operator    0,  97 12月 11 09:12 ada1
crw-r-----  1 root  operator    0, 112 12月 11 09:12 ada1s1
crw-r-----  1 root  operator    0, 119 12月 11 18:12 ada1s1d
crw-r-----  1 root  operator    0, 121 12月 11 18:12 ada1s1e

昔のデバイスはリンクになってるわけか。 話だと、古いデバイス名のままだと有効にならない機能もあるとかで、やはり直したほうがよさそう。

/etc/fstab 修正して再起動。